In instances like this, there's no issue with it being ES5.
However, in the web world, ES6 modules have a huge (pardon the pun) advantage that's just being realized. Because of the static nature of ES6 imports, you can eliminate unused code when you package it all together. The newest Webpack versions and Rollup are both taking advantage of this, and it can result in huge savings in filesize.
For example, lodash is a large library with hundreds of methods, and a lot of the time people only use 3 or 4 imports from it. If you use an ES5 version, you'll get all of those functions in a compiled bundle no matter what. If you use an ES6 version with Webpack 2, all the methods you use will end up being the only ones that are actually included in the final code.
I imagine most libraries has some common functions that ones from public API rely on (and of course some exports can be used within module itself).
Let's say you never import `helperX` and `helperY` from a library, but you import `usefulFunction` which relies on `helperX`. How would webpack know to exclude `helperY` but not `helperX`?
Unless it does some kind of code analysis, or lib is split in "module per function" or similar manner, I can't really see a way to achieve it. And if library is common core plus a bunch of modules per function it exports, how is that different in CommonJS versus ES6 modules?
That's why it only works with ES6 imports. ES6 imports must be made at the top of the file, and aren't dynamic. You must explicitly import what you need.
Additionally, this method only works with named imports. So for example, you can have two files:
File a.js
export a = 5;
export b = 6;
export c = 7;
export d = 8;
export default {a, b, c, d};
File b.js
import {a, b} from "./a.js";
console.log(a);
console.log(b);
c/d will never be included in the output file, nor will the default export. However, if you do:
import a from "./a.js";
Then it won't optimize at all, because all of those objects are referenced in the default export.
Note that it's possible I'm wrong as to the specific optimization method, but largely speaking this is how it should work.
That much makes sense, but if I understand GGGP's example properly, they are talking about pruning unused internal references within a module, but GGP's response implies that somehow Rollup will prune those out.
Ah, I understand the confusion now. I'm not 100% sure how that code works, but I do know it uses estree and that case is tested for, nearly verbatim. Here's a link to the source which handles that sort of stuff.
However, in the web world, ES6 modules have a huge (pardon the pun) advantage that's just being realized. Because of the static nature of ES6 imports, you can eliminate unused code when you package it all together. The newest Webpack versions and Rollup are both taking advantage of this, and it can result in huge savings in filesize.
For example, lodash is a large library with hundreds of methods, and a lot of the time people only use 3 or 4 imports from it. If you use an ES5 version, you'll get all of those functions in a compiled bundle no matter what. If you use an ES6 version with Webpack 2, all the methods you use will end up being the only ones that are actually included in the final code.