Recently I stumbled upon a library for nodejs, that I want to use in a frontend project. Because the whole project is developed in ES6, the library should not be transpiled (we only develop for browsers, supporting es6). Of course, I could "browserify" manually, but because it can be a reoccurring task, I would like to use browserify without babelify or any es6 transpilation process.
If transpilation is needed later on, I'd integrate it into the whole build process, but not beforehand.
Is there any option to browserify to omit es6 to ecmascript-5.1 transpilation?
By default, browserify does not do any transpilation process, if no plugins are enabled. It turned out, that the library I wanted browserify, passed some options to browserify in its package.json:
"browserify": {
"transform": [ [ "babelify", { "presets": "es2015" } ] ]
}
this caused browserify to use the babelify plugin by default.
Related
Situation
So I have a .babelrc like this:
{
"presets": [
"es2015",
"stage-2",
"react"
],
"plugins": [
"transform-decorators-legacy"
]
}
Question
What is the difference between presets and plugins? Which one should I use to configure Babel?
tl;dr
Presets are just a collection of plugins. You can include plugins individually in the plugins array, or collection of plugins in the presets array. If a plugin is part of a collection (preset), you don't have to include it individually in plugins.
The same goes for npm packages when you include them in package.json.
Presets vs Plugins
Babel has lots of official and third party plugins. Presets are collections of plugins or as they say:
Presets are sharable .babelrc configs or simply an array of babel plugins.
An important difference between the two is that plugins are loaded before presets.
Plugins of a preset
The most common presets are the official ones and the discontinued experimental presets.
Most of the official presets contain plugins to transpile features of the EcmaScript standards, while the experimental (stage-x) presets contained plugins that transpiled future experimental features whose standardization is still a work in progress. These experimental/proposal presets are deprecated since Babel 7. They have a blog entry on the reasons. Read the section below to see how they worked.
When you click on a preset, you can see which plugins (and maybe other presets) are included in it. If you include a plugin via a preset you don't have to include it individually. The same goes for package.json when you include the npm packages of the presets.
Deprecated proposal preset system
Going from stage 0 (just an idea) to stage 3 (candidate) you had collections of plugins that were more closer to getting standardized. Because of this, when you included a preset, every preset with a higher stage-x value were included too. The plugins contained in these presets were continuously varying in each version, since they are a work in progress, and there is a chance that plugins will be removed if they got rejected. That is why you needed transform-decorators-legacy because, decorator transpiling was earlier removed from Babel, although they added it back later.
I'm trying to figure out if it is worthwhile moving to webpack, I am leaning towards saying no - figuring I have more important stuff to do - but I would like to see some practical examples of how to make webpack work.
So if I have the following Gulp.js task how would I do them as a webpack task?
gulp.task('subpaths', ['clean_subpaths'],function() {
//Minify and copy all JavaScript (except vendor scripts)
gulp.src(paths.subpath_scripts)
.pipe(fileinclude({
prefix: '##',
basepath: '#file'
}))
.pipe(contextswitch())
.pipe(uglify())
.pipe(strip())
.pipe(rename(function (path) {
path.basename += timestamp;
}))
.pipe(gulp.dest('public/longcache/javascripts/subpath'));
});
So the tasks above do -
include files inside of other files for processing.
run the piped content through my own defined code - I guess in webpack
that would be run my own plugin?
uglify
remove console statements
rename the output file so it has a version.
write out to a specific location
The first item -- include files inside of other files -- is one of webpack's biggest benefits, speaking as someone coming from an all grunt/gulp workflow. Instead of managing dependencies externally (in your build tools), and having to ensure that files are combined correctly based on their runtime dependencies, with webpack your dependencies are part of the codebase, as require() expressions. You write your app as a collection of js modules and each module loads the modules it relies on; webpack understands those dependencies and bundles accordingly. If you're not already writing your js in a modular fashion, it's a big shift, but worth the effort. This is also a reflection of what webpack is meant for -- it's conceptually oriented around building a js application, not bundling some js that your site uses.
Your second item would more likely be a custom loader, which is easier to write than a custom plugin. Webpack is very extendable, throughout, but writing custom integrations is poorly documented.
Webpack's Uglify plugin will also remove console.logs, super easy.
Specifying output details is part of your basic webpack config, just a couple of options to fill in.
I'm using pdf.js in an angular project. Building with gulp in production mode works fine, but the production build produces non-working code that fails silently without and warnings or errors, whatsoever. I never get a viewer canvas.
It turns out the problem lies not with minification, but rather with concatenation.
The dist directory of the pdfjs-dist bower package contains three files:
pdf.js
pdf.worker.js
pdf.combined.js
the bower.json file list pdf.js and pdf.worker.js, but when using gulp bower copy and concatenation you should use pdf.combined.js instead of the other two. Add an override to your projects bower.json
"overrides": {
"pdfjs-dist": {
"main": [
"build/pdf.combined.js"
]
}
}
Is it possible to transpile using babel.transform without touching the JSX? I would like to leave the JSX in place to use an alternative JSX interpreter which is to be performed after the Babel transpilation takes place.
Normally when transpiling JSX, you'd have a configuration like
{
presets: ['es2015', 'react']
}
In your case however, you're essentially looking to leave out 'react` without causing Babel to throw a syntax error for JSX. This can be accomplished by only enabling the plugin for the parsing JSX syntax without enabling the plugin for converting JSX into JS: http://babeljs.io/docs/plugins/syntax-jsx/
{
presets: ['es2015'],
plugins: ['syntax-jsx']
}
and ensuring you install the plugin with npm install --save-dev babel-plugin-synax-jsx.
I have just started using Webpack via a recommendation and am looking for some guidance on how it should be implemented for build and deploy purposes.
I currently have it up and running nicely using webpack-dev-server and some Gulp tasks.
Traditionally I would use Gulp or Grunt to concat files among other things and then use the task runner to copy all my files and assets to a dist or build directory from where I would deploy everything.
At the minute, Webpack does it's thing and builds the bundle file, images etc and then copies them to the build dir, using the [hash].js naming convention.
So my question is, what is the standard practice for then copying over my index.html file and then correctly linking it to the js file to be used in production.
Unless I am completely misunderstanding how Webpack should be used, should there not be some way for me to do this, with the ultimate outcome being me having the ability to navigate to the build dir and see my app up and running as it should be?
I am currently using a plugin to move my index.html. Make sure your webpack.output.publicPath points to your site so it can link images and other resources.
var CopyWebpackPlugin = require('copy-webpack-plugin');
var webpack_config = {
//Other configs here
output: {
publicPath: 'http://localhost/'
},
//Other configs here
plugins:[
new CopyWebpackPlugin([
{from: './index.html', to: './index.html'},
], {
ignore: [
'*.txt',
{glob: '**/*', dot: true}
]
})
],
//Other configs here
}