Add support for ES6 import syntax

[romeovs]

This might be a long shot but I'd like to see this in browserify.

The ES6 module syntax has a few nice features compared to commonJS require method,
namely bindings and cyclic dependencies.

Since these things are in the ES6 standard it seems reasonable to work them into browserify too!

Note that just using a ES6 to ES5 transpiler wouldn't work in this case because these are cross module concerns.
For instance, babelify is only able to transpile import foo from 'foo' to var foo = require('foo') at file-level, but this does not allow cyclic dependencies.

The Esperanto project has a nice way of handling things but lacks too many features to be a valid replacement for browserify.

Is there any possibility to see support for ES6 import syntax come to browserify?

I've been waiting for this feature to land in node first so browserify can match the semantics properly. I'm also concerned that if browserify implements a default es6 import mechanism while node doesn't have one, it will needlessly fragment browser and server ecosystems.

[romeovs]

Yes, my approach to writing modules is currently to write them in ES6 but only expose ES5-compliant
code (transpiling everything on npm publish for example).

I get your concerns, and they are indeed important ones.

How feasible would you say it is to expose this as a plugin for browserify (I'm currently looking into
writing that).

[romeovs]

I've created a small gist with a proof of concept for a plugin. I'll start working on it!

[nmn]

@romeovs
You can already use a transform like babelify to get ES6 imports. With both Node and Browserify. You can turn off the other features if you don't want them.

[romeovs]

@nmn but do these imports with babelify have the complete ES6 semantics?
As far as I can see they just transform the import statements into require statements, but require and import have different semantics with respect to bindings and cyclic dependencies.

The problem is really the way browserify concatenates the imported files. esperanto does this correctly, but lacks other features that make browserify a much better choice.

[romeovs]

@nmn after some testing I can see that it does!

[fregante]

I think @substack is right in waiting for proper node support. browserify brings node to the browser; if node doesn't support import, browserify shouldn't either.

If babelify doesn't follow the right semantics, raise the issue with them or ask for an esperantify plugin.

[flyingrobots]

How about now?

[yoshuawuyts]

It appears a good deal of fragmentation will start occurring because of d3@4.0.0 relying on es6 imports. It's not seen an official release yet, but given the buzz around its components I think it's already becoming somewhat of an issue.

I know that Node doesn't support ES6 imports quite yet, but arguably browserify is in a somewhat different spot since it doesn't support dynamic imports (or at least I don't think it does out of the box).

The reason why I think we should consider options is because if other loaders become popular because of only a single feature, it might signal there's a need for it.

I'm not quite sure what the correct resolution is; for the package I'm writing that consumes d3 I might include a compiled build (breaking npm reliance) or include babelify (making the package very heavy) - though neither is ideal. Perhaps an importify transform needs to be written, or perhaps this should be resolved at the browserify level - I'm not sure.

For now I'm posting this here to signal that changes are happening, and we'll probably need to think of a solution for this 😕

edit July 2016: nope nope, we shouldn't move ahead on import unless Node does so (which it frankly might not, so hey)

[terinjokes]

@yoshuawuyts Implying that d3@4.0.0 only works with loaders that support ES6 modules is a bit disingenuous. The main field in the root's package.json and the individual modules all point at Node.js compatible files (and I'm successfully using several d3 modules with Browserify just fine)

[dantman]

Browserify's greatest feature is the transform pipeline (heck the parts that actually break require into a dependency tree and combine that tree into a bundle aren't even in this repo, they're the module-deps and browser-pack packages) and the collection of transforms we have that make . IMHO rollup's greatest feature is not ES6 imports, but the static analysis and tree shaking it does. So even if browserify rushes to hastily implement non-babel ES6 import support before any JS engine natively supports it, I doubt that'll stop may people from using rollup.

There are already a pile of other packages using ES6 import; but they all do it alongside the use of other ES2015 features. So I expect packages like d3 that only use ES6 import is going to be a rarity. And the moment you use any other feature, you need Babel, whether you're using rollup or browserify. So I doubt "rollup lets me use packages that only use ES6 import without needing Babel" will be the reason people use rollup.

I think the problem browserify is going to have is rollup's plugins. That functionality is what turns rollup from just a tool to pack up ES6 exports/imports into something that can pass as a standalone loader.

Rather than trying to hack ES6 import in with require schematics, just as a way to bypass babel in a few cases (because if you use Babel this is already entirely possible). I think it would be better to accept the area that rollup is better at (tree shaking ES6 imports) and find a way to break up rollup and create a rollupify plugin that will integrate rollup's tree-shaking and also act as an optional ES6 import handler for those that don't want to use babelify.

---

It's a different topic. But I think browserify's other undoing may be how easy it I've seen it is to make a simple transform but hard it is to make one that correctly preserves source maps. I don't see any easy tools for source-map aware string manipulation. And while I'd love to transform using an AST, that's not viable when each transform has to source -> parse to AST -> transform -> AST to source -> source instead of sharing an AST. At this point, in my own code, I can't tell if my source maps work or not anymore and I have no clue which piece might be at fault for messing with them.

[jokeyrhyme]

FYI: there's an enhancement proposal for Node.js being discussed here regarding ES2015 modules:

• 002: ES6 module interop nodejs/node-eps#3

[gregtatum]

Coming in to say I'm actively getting issues because d3's latest version is only using ES6 syntax. I can't use my browserify tooling now. The time seems ripe for this change as the ecosystem has already begun the move, otherwise I think browserify will have lost its relevance in this increasingly competitive bundling space.

[jmm]

Hello @TatumCreative. D3's README says their releases support CommonJS. Is that not the case? Even so, there are multiple tools for compiling ES6 module syntax to CJS -- can you not use one of those?

[gregtatum]

Hmm... Yeah my bad. It looks like user error on my part. Sorry about that. My opinion still stands though. Three.js just landed a big patch to go the ES6 route as well. Personally I'm in a weird position as I tend to primarily target one browser and I want what Browserify does with bundling without the side-effect of mangling my ES6 code and turning it into ES5 code.

I can probably come up with a solution if I do more research, but regardless I still feel it is important to support ES6 imports sooner rather than later, as the community is already adopting it in projects. I feel like fragmentation is happening as people have moved on to other bundling solutions, which I would really not have to do, as I really love the browserify tooling ecosystem. All that said, I probably don't have the time to contribute to this project to make it happen, and I appreciate the work everyone does here!