Enable babel-preset-env for node_modules that target newer Node versions

[julien-f]

Hello,

More and more npm packages contain ES2015+ code (for now usually features supported by Node 4 but i guess it will move to Node 6 features once 4 will be unmaintained). Unfortunately, this breaks compatibility with Uglify and browsers.

The only answer to this is, IMHO, to also transpile external dependencies. Is this supported by create-react-app?

I'm asking because my own build set up is getting confronted to this and I'm thinking about migrating to create-react-app :)

[gaearon]

No, this is not supported because builds will get much slower. We don't recommend using libraries that don't precompile their code to ES5 but are supposed to be usable in ES5.

We will fix the Uglify problem in the future by using Babili. However it still means that even uglified code will still be ES6 if that's what your dependencies are shipping.

With time it won't matter as much because mainstream browsers will support ES6. Until then I recommend to use libraries that take care of transpilation step.

[julien-f]

I understand but it creates a dichotomy between Node's and browsers' worlds, which will lead to less isomorphic JavaScript components/libraries :/

@sindresorhus, you have migrated many of your packages to ES2015, what's your opinion on this?

And, once Uglify as been replaced by Babili, I'm not sure it'll have a big impact to add other Babel presets to the compilation pass (@hzoo, any inputs on this?)

[julien-f]

Concerning the perf impact, I guess it depends of how many times the code is parsed/generated, it would be interesting to have everything done in a single one but it probably depends on the bundler (Webpack).

[gaearon]

OK, let’s keep it open and wait for more feedback.

The cold start time is pretty bad. I saw an increase from 6 to 20 seconds on a relatively small app.

However, since we enable caching for Babel loader, warm start stays 6 second.
So maybe it’s not such a big deal.

[gaearon]

I would be comfortable doing this if:

• We are sure that enabling Babel never breaks third party code. I’m actually not at all sure this is true.
• We are sure only cold start suffers, both for npm start and npm run build, and that whatever caches we are using work well for next start, for edits while it is running, and for builds.

[julien-f]

I understand very well your pain about long compile time, but I think the answer is somewhere because with bundling, tree-shaking and minification, this code is already parsed.

Maybe the work is more on the ecosystem side (Babel, Webpack, etc.) to avoid doing unnecessary operations (parsing and generation).

[hzoo]

Running babel on all of node_modules does sound really slow - right it might be faster (would need to measure) passing an AST to webpack or vice versa.

[julien-f]

@hzoo but if Babili is used, the code won't get much slower by adding other Babel plugins/presets right?

At least much faster that Babel + Uglify.

[gaearon]

I understand very well your pain about long compile time, but I think the answer is somewhere because with bundling, tree-shaking and minification, this code is already parsed.

To be fair there is no minification in development.

[julien-f]

To be fair there is no minification in development.

Seems logic, but watch mode may be enough to mitigate the issue…

[gaearon]

At this point I’m more concerned about correctness than speed.
My gut tells me some projects will break if you Babel them.