I'm trying to migrate the following browserify workflow into a single gulp task:
package.json:
"scripts": {
"build": "browserify src/main.js > dist/build.js"
},
...
"browserify": {
"transform": [
"vueify",
"babelify"
]
}
.babelrc file:
{
"presets": ["es2015"]
}
Since gulp-browserify is now longer maintained, I used this recipe to get the whole workflow into a single gulp task:
gulp.task('build', function () {
var b = browserify({
entries: './src/main.js',
debug: true,
transform: [vueify, babelify.configure({presets: ["es2015"]})]
});
return b.bundle()
.pipe(source('build.js'))
.pipe(buffer())
.on('error', gutil.log)
.pipe(gulp.dest('./dist/'));
});
Unfortunately, the generated build.js files are different and only the build.js file generated by the command npm run build is running my Vue.js App properly.
I just managed to get past this problem myself. After spending a bit of time in the debugger I found that the array of transforms used by browserify contained 'babelify' and 'vueify' twice.
What happens then is probably that the transforms are applied like so: bablify -> vueify -> babelify -> vueify. I didn't spend much time figuring out exactly how that blew up my stuff since the problem is easy enough to get rid of.
Either specify browserify transforms in package.json OR in your gulp file. Not both.
Related
For a library written in ES6/7, I want to compile (to ES5) the library to a dist/ folder. I also want to run the tests (written in ES6/7) for this lib.
My dev dependencies look like this (package.json):
"devDependencies": {
"#babel/cli": "^7.4.4",
"#babel/core": "^7.4.5",
"#babel/preset-env": "^7.4.5",
"#babel/register": "^7.4.4",
"chai": "^4.2.0",
"mocha": "^6.1.4",
"sinon": "^7.3.2"
},
My build and test scripts looks like this (package.json):
"scripts": {
"test": "mocha --require #babel/register",
"build": "babel src -d dist --presets=#babel/preset-env"
},
Running npm run build works well. The dist/ folder gets populated with transpiled files.
Running npm run test does not seem to work - this is my problem.
> mocha --require #babel/register
/Users/dro/Repos/lib/node_modules/yargs/yargs.js:1163
else throw err
^
ReferenceError: regeneratorRuntime is not defined
Initially I got an import error, which was resolved by adding .babelrc file.
Below is my .babelrc file content.
{
"presets": ["#babel/preset-env"]
}
I was reading about regeneratorRuntime and it got me to this link about babel-polyfill where they explain I shouldn't need that polyfill.
This will emulate a full ES2015+ environment (no < Stage 4 proposals) and is intended to be used in an application rather than a library/tool.
What is needed to set this up properly?
I am not using webpack.
Testing in ES6 with Mocha and Babel 7. Look here: https://dev.to/bnorbertjs/my-nodejs-setup-mocha--chai-babel7-es6-43ei or http://jamesknelson.com/testing-in-es6-with-mocha-and-babel-6/
npm install --save #babel/runtime
npm install --save-dev #babel/plugin-transform-runtime
And, in .babelrc, add:
{
"presets": ["#babel/preset-env"],
"plugins": [
["#babel/transform-runtime"]
]
}
Look at the project documentation:
npm install --save-dev babel-register
In your package.json file make the following changes:
{
"scripts": {
"test": "mocha --require babel-register"
}
}
Some features will require a polyfill:
npm install --save-dev babel-polyfill
{
"scripts": {
"test": "mocha --require babel-polyfill --require babel-register"
}
}
Below steps are for applying Babel transformations & core-js polyfills for your tests file:
💡 All transformations are only done per current environment, so only what is needed to be transpiled/polyfilled, will be. Target environments may be defined from a .browserslist file or as a property in package.json file. (read more here)
Step 1: Install packages:
#babel/core (read why)
#babel/preset-env (read why)
#babel/register (read why)
core-js (read why)
Note that #babel/polyfill exists and uses core-js under the hood. However, it was deprecated in favor of using core-js directly.
Step 2: Create a Babel configuration file babel.config.js
(used to be .babelrc.js or a .json file).
Create this file at the root-level of your code.
The most basic configuration (for just testing and not bundling) would look like this:
module.exports = {
presets: [
['#babel/preset-env', {
"corejs": "3.26",
"useBuiltIns": "usage"
}],
};
corejs - This is the polyfills library and should be specified with the minor version, otherwise x.0 will be used.
It is needed when testing code on rather "old" Node versions, which do not support all of the language methods. This ofc depends on your own usage of such javascript methods. (for example String.prototype.replaceAll).
useBuiltIns - must be set in order for the corejs polyfills to be applied. Read about it in the official docs.
By default, #babel/preset-env will compile your code for the current environment, but you can specify a different environment by setting the "targets" option in the configuration.
Ofc, you can add more presets like #babel/preset-react for example, if your code it written in React, or any other plugins which are specifically needed for your code.
Step 3: Connect mocha to the babel configuration:
In your package.json file
Under the scripts section, simply write something like this:
"test": "mocha \"src/**/*.test.js\""
Create a .mocharc.json file with this content:
{
"exit": true,
"color": true,
"require": ["#babel/register"],
"ignore": "node_modules"
}
This will apply Babel transformations to all of your test files.
If you need need to apply some special global javascript before/to all of your tests, you can add another file to the require setting, for example, fixtures.cjs:
"require": ["#babel/register", "fixtures.cjs"],
fixtures.cjs:
Below example applies a chai (popular alongside Mocha) plugin for testing DOM-related code:
var chai = require('chai'),
chaiDOM = require('chai-dom');
// https://stackoverflow.com/questions/62255953/chai-usechaihttp-once-or-in-every-test-file
// https://mochajs.org/#global-teardown-fixtures
exports.mochaGlobalSetup = function () {
chai.use(chaiDOM);
}
Interesting reads:
Babel vs babel-core vs babel-runtime
How does mocha / babel transpile my test code on the fly?
I am trying to find a proper configuration for the publishOptions inside project.json (ASP.NET Core 1.0 / Full Framework) so that non-minified files are not published.
Official documetation doesn't help much: project.json reference.
Searching for globbing patterns, and finding some artilcles with gulp examples, I came up with this wwwroot/js/**/*!(*.min.js), but it doesn't seem to work.
Is my syntax wrong? Or, it's just that project.json and dotnet publish don't support this syntax?
"publishOptions": {
"include": [
"wwwroot",
"Views",
"Areas/**/Views",
"appsettings.json",
"web.config"
],
"exclude": [
"wwwroot/lib",
"wwwroot/js/**/*!(*.min.js)",
"wwwroot/css/*.less",
"wwwroot/_references.js"
],
"includeFiles": [],
"excludeFiles": []
},
The typical workflow for JavaScript files/libraries management is to use gulp or grunt tasks to copy over the necessary files into the wwwroot folder which may happen on certain events (prebuild, postbuild, project open, clean).
In the latest tooling, the default MVC doesn't include gulpfile.js anymore as the most common usage was to minify and bundle js files, even when no external libraries were used so gulp may be a bit overwhelming for new users.
But it can easily be brought back, when you right-click the bundleconfig.json file in the solution explorer and choose "Bundler & Minifier" > "Convert to Gulp".
This creates a gulpfile.js and package.json (nodejs dependencies) in the root of your project and adds npm folder to the "Dependencies" section of Solution Explorer. When you watch in the Windows Explorer, you'll see a node_modules folder in the project root folder. That's where npm will download all packages and it's dependencies.
The generated gulpfile.js looks like this and has a few predefined tasks. i won't use this file as example, as it is strongly based on the bundleconfig.json and it's structure and use my gulpfile.json which used to be shipped with older templates.
"use strict";
var gulp = require("gulp"),
rimraf = require("rimraf"),
concat = require("gulp-concat"),
cssmin = require("gulp-cssmin"),
uglify = require("gulp-uglify");
var webroot = "./wwwroot/";
var paths = {
app: webroot + "app/",
libs: webroot + "lib/",
js: webroot + "js/**/*.js",
minJs: webroot + "js/**/*.min.js",
css: webroot + "css/**/*.css",
minCss: webroot + "css/**/*.min.css",
concatJsDest: webroot + "js/app.min.js",
concatCssDest: webroot + "css/app.min.css"
};
gulp.task("clean:js", function (cb) {
rimraf(paths.concatJsDest, cb);
});
gulp.task("clean:libs", function (cb) {
rimraf(paths.libs, cb);
});
gulp.task("clean:css", function (cb) {
rimraf(paths.concatCssDest, cb);
});
gulp.task("clean", ["clean:js", "clean:css", "clean:libs"]);
gulp.task("min:js", function () {
return gulp.src([paths.js, "!" + paths.minJs], { base: "." })
.pipe(concat(paths.concatJsDest))
.pipe(uglify())
.pipe(gulp.dest("."));
});
gulp.task("min:css", function () {
return gulp.src([paths.css, "!" + paths.minCss])
.pipe(concat(paths.concatCssDest))
.pipe(cssmin())
.pipe(gulp.dest("."));
});
gulp.task("min", ["min:js", "min:css"]);
gulp.task("libs", function (cb) {
gulp.src([
'bootstrap/**/*.js',
'bootstrap/**/*.css',
'jquery/**/*.js`, // we can also limit this to `jquery/dist/**/*.js to only include distribution files
'jquery/**/*.css'
], {
cwd: "node_modules/**"
})
.pipe(gulp.dest(paths.libs));
});
gulp.task("app", function (cb) {
gulp.src([
'app/**.js'
])
.pipe(gulp.dest(paths.app));
});
gulp.task("default", ['clean', 'libs']);
It looks more complicated than it actually is. There are several minizier tasks (min:js, min:css) and one general minifier task min which just runs all others in sequence.
A clean task which deletes the output file(s) from wwwroot. When converting from the template, it deletes only the default wwwroot/js/site.min.js file.
Since there are no javascript libraries used in the default template, except of what's inside the wwwroot/lib folder already the packages are not handled that way.
So first thing you may want is to grab bootstrap and jquery from npm rather than the static versions provided by the template. So we add the dependencies to the package.json.
{
"name": "app",
"version": "0.0.0",
"private": true,
"dependencies": {
"bootstrap": "3.3.6",
"jquery": "2.2.0"
},
"devDependencies": {
"gulp": "3.8.11",
"gulp-concat": "2.5.2",
"gulp-cssmin": "0.1.7",
"gulp-uglify": "1.2.0",
"rimraf": "2.2.8"
}
}
The libs task from the gulpfile.js above for example will copy over all required files of a package to wwwroot. I said required, because in the packages there are often unbundled files for debugging and stuff, which we usually don't want inside wwwroot (they can grow quite big).
gulp.task("libs", function (cb) {
gulp.src([
'bootstrap/**/*.js',
'bootstrap/**/*.css'
], {
cwd: "node_modules/**"
})
.pipe(gulp.dest(paths.libs));
});
It will look for all *.js and *.css files within the bootstrap folder in node_modules folder and copy them over to path.libs which is configured as wwwroot/lib/.
The app task does the same for our own code. clean clears the folders and (i.e. before switching from debug to release build or before publishing).
Finally you can bind the tasks to certain VS Events. You need to open the "Task Runner Explorer" View (View > Other Window > Task Runner Explorer). There you can choose a task and right-click it, then "Binding" and choose one of the binding (Before Build, After Build, Clean, Projct Open). They are pretty self explaining, "Clean" means when you do "Build > Clean Solution".
Now to the publishing part. You can run certain command, when you publish your application (either via dotnet or Visual Studio).
In the project.json there is a scripts section for this.
"scripts": {
"prepublish": [ "npm install", "bower install", "gulp clean", "gulp min", "gulp libs" ],
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}
Each of the entries "prepublish" is one command to be executed. In this example, before the publishing begins, npm install will be executed first in order to restore all npm dependencies. Then bower install to install the dependencies managed by bower (remove it if you don't use bower and do all via npm).
The next three commands are the interesting ones, they will execute gulp tasks. We can also simplify this by adding a "publish" task.
gulp.task("publish", ['clean', 'libs', 'min']);
"scripts": {
"prepublish": [ "npm install", "bower install", "gulp publish" ],
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}
This will copy all the necessary files for publishment into the wwwroot folder, publish the files and then call the "postpublish" scripts.
That's a rough introduction in gulp. It's has a learning curve, but once you get it working it imrpoves the overall workflow.
What's not covered here is to add a watch task which may look into a certain folder (I usually use app folder in the project root) and when any file changes there run the app task, so the our code gets minifed and copied over to wwwroot and is available when we debug it.
A simple alternative is:
Rename unminified source to *.debug.js and *.debug.css
They are now easier to exclude:
"publishOptions": {
"include": [
"wwwroot"
],
"exclude": [
"wwwroot/**/*.debug.*"
]
}
IMHO unminified source should stick out and look abnormal. It is more deserving of a file name wart than minified code.
This also brings the build output files into line with the rest of the .Net build configuration. It makes it clear that your debug versions may well include extra logging and debug utilities and that its not for production.
I´m trying to setup a build workflow using the aforementioned technologies, but I´m getting the following error, which seems very generic upon running tests on karma:
TypeError: 'undefined' is not an object (evaluating 'a.Sifter=b()')
This happens even without adding any ECMSA6 specific feature. The same workflow works fine without the transpiling phase in the workflow.
What I tried was to set the babeljs after a concatenation phase and before executing a uglifying on it, like the following snippet:
var defaultTasks = [
"sass:prod", // compile scss sources
"cleanAll", // clean folders: preparing for copy
"copyAll", // copying bower files
"cssmin:customVendor", // minify and concat 'customized from vendor' css
"concat:vendorStyles", // concat vendors's css + minified 'customized from vendor' and distribute as 'css/vendor.css'
"uglify:rawVendors", // minifies unminified vendors
"concat:vendorScripts", // concat vendors's scripts and distribute as 'scripts/vendor.js'
"ngAnnotate:app", // ng-annotates app's scripts
"concat:appScripts", // concat app's (customized from vendor's + ng-annotated + customer's)
"babel",// uses babeljs to convert brandnew ES6 javascript into ES5 allowing for old browsers
"uglify:app" // minify app script and distribute as 'scripts/app.js'
];
if (!skipTest) {
defaultTasks.push("karma:target"); // run tests on minified scripts
}
The imporant definitions are shown:
babel: {
options: {
"presets": ['es2015']
},
dist: {
files: {
"<%= concat.appScripts.dest %>": "<%= concat.appScripts.dest %>"
}
}
},
uglify: {
options: {
mangle: {
except: [
"jQuery", "angular", "tableau", "LZString", "moment", "Moment", "Modernizr",
"app", "modules"
]
}
},
app: {
files: [{
src: ["<%= concat.appScripts.dest %>"],
dest: "<%= app.dist %>/scripts/app.js"
}]
}
},
I´ve tested the transpile a bit, running the default logic from babel url, and it works well, converting basic stuff.
Is there any better workflow that I could use to still run the tests against the same code that would be executed for real?
Thanks
In the end, the workflow was correct.
I just need to modify the filesets a bit in order to avoid transpiling the selectize.js file (which wasn´t really needed).
However, not sure why it was breaking
That solved to me, so I´m closing the question, but perhaps might be useful for someone else.
The FileAPI library (https://github.com/mailru/FileAPI/issues/202) does not officially support CommonJS modules. I've tried using browserify-shim but I'm not able to make it work. After requireing fileapi I just get an empty object back. I've created a repo for reproduction here https://github.com/Prinzhorn/browserify-fileapi
Relevant package.json part
{
"dependencies": {
"fileapi": "2.0.15"
},
"devDependencies": {
"browserify": "11.1.0",
"browserify-shim": "3.8.10"
},
"browser": {
"fileapi": "./node_modules/fileapi/dist/FileAPI.html5.js"
},
"browserify-shim": {
"fileapi": "FileAPI"
}
}
If you want to try it locally:
git clone git#github.com:Prinzhorn/browserify-fileapi.git
npm install
npm run build
chromium-browser index.html
Check out the console in Chromium, you'll see an empty array from running console.log(Object.keys(require('fileapi'))). Note that there is a global window.FileAPI with the correct API.
Does anyone know if browserify-shim is able to shim FileAPI? Because I believe it does some exotic things to manage it's dependencies (the concatenated files expect certain globals).
You'll need to tell browserify to use browserify-shim as a transform in the package.json as outlined in this example
Mainly you're missing:
"browserify": {
"transform": [ "browserify-shim" ]
}
I am publishing a library to NPM.
When I build the library, the resulting artifact is placed in the dist folder located in the root of my project as index.js.
When users install from NPM I would like index.js to be present in the root of the folder created in their node_modules folder. Presently, it remains in a directory named dist.
How can I do this?
My packages.json:
{
"name": "my-package",
"version": "0.0.9",
"files": ["dist/*"],
"main": "index.min.js",
"private": false,
"dependencies": {},
"devDependencies": {},
"repository": "git#github.com:username/my-package.git"
}
I had exactly the same problem.
I solved it not by copying the files up, but by copying the files I needed down into the ./dist/ folder and then doing an npm publish from there; NPM then treats that folder as a complete package and everything works very nicely. The only files I needed to copy from the root folder were:
package.json
README.md
Because we're going to copy these files down into the ./dist/ folder before we do the publish, we do NOT want the package.json file to reference ./dist/. So remove the package.json's files entry completely, because we don't need to tell it which files we'll take - we're going to take everything in the ./dist/ folder. I'm using TypeScript so I also have a typings entry, and again no reference to ./dist/.
{
"name": "my-package",
"version": "0.0.9",
"main": "index.min.js",
"typings": "index.d.ts",
"private": false,
"dependencies": {},
"devDependencies": {},
"repository": "git#github.com:username/my-package.git"
}
Now for the publish step. I built a gulp task that will perform the publish for me, making it nice and automated (except for incrementing the package version #).
From gulp I'll use Node's spawn() to kick-off the npm process. However, because I'm actually working on Windows I used "cross-spawn" rather than the normal built-in Node.js spawn (which I learned the hard way didn't work when I had spaces in my path!).
Here's my gulp file, with the TypeScript bits removed:
var gulp = require('gulp');
var del = require('del');
var spawn = require('cross-spawn'); // WAS: require('child_process').spawn;
var config = {
src: { tsFiles: './src/**/*.ts' },
out: { path: './dist/' }
}
gulp.task('clean', () => {
return del('dist/*');
});
gulp.task('build', ['clean'], () => {
....
});
gulp.task('publish', ['build'], (done) => {
// Copy the files we'll need to publish
// We just use built-in gulp commands to do the copy
gulp.src(['package.json', 'README.md']).pipe(gulp.dest(config.out.path));
// We'll start the npm process in the dist directory
var outPath = config.out.path.replace(/(\.)|(\/)/gm,'');
var distDir = __dirname + '\\' + outPath + '\\';
console.log("dist directory = " + distDir);
// Start the npm process
spawn('npm', ['publish'], { stdio:'inherit', cwd:distDir } )
.on('close', done)
.on('error', function(error) {
console.error(' Underlying spawn error: ' + error);
throw error;
});
});
Notice when we call spawn() we pass in a 3rd argument which is the options. The main entry here is the cwd:distDir, which tells spawn to run the npm process from the ./dist/ directory. Because using spawn can cause problems I've hooked into the spawn error handling. As I was troubleshooting my use of spawn() I found the following StackOverflow article very helpful.
This worked like a charm; my published package has all the files in the root directory and the ./dist/ folder is not published.