Complexity in 5 not well laid out

[martinheidegger]

As a side note I think you may be missing a complexity of your proposal in this regard (unless I'm missing something), how is one to migrate to ES6 modules piecemeal?
(from @robbiespeed)

[martinheidegger]

(I am not familiar with this use of piecemeal so I guess it means in steps.)

If you have a package that you want to transfer in steps from CommonJS to ES2015 then what you do is: deploy it as CommonJS and use Babel or something similar until you have separated them. What about this is heavy complexity? This is how we make ES2015 packages right now?!

[ljharb]

It is unreasonable imo to tell me that i must not use native ES modules until my entire package or app is migrated. I need to be able to use native ES modules and commonJS modules alongside each other, transparently, so that migrating one file requires zero changes in the files requiring it.

[martinheidegger]

It would be very good for the understanding of me and other Node.js members to explain why it is unreasonable to you? Why is a Babel based solution in that case not acceptable?

[ljharb]

Babel isn't using ES modules, it's just using syntax sugar over require and module.exports. One of the future benefits of ES modules is static analysis and dependency graph analysis - I wouldn't be able to do this in the same way with transpiled modules.

[martinheidegger]

Yes, you would need tools that bake it into the babel compiler. Note that graph analysis would be strongly impeded by mixed module packages.

[ljharb]

Another use case is that I might have Module code in node, in the same app as I have CJS code that I browserify and send to the browser, or vice versa.

[martinheidegger]

The package specification applies only to how Node.js has to deal with the code. You can still specify how browserify or babel treats other parts of the code. (and put CommonJS files in a ES2015 package or vice versa). Don't see how this would break.

My summary of the above discussion is following:

You want to have mixed packages because you can not update at once but you want to use ES2015 features. That doesn't make any sense to me. If you want to use ES2015 features: move your project to ES2015?!

Can we agree that this argument is weak?

[ljharb]

Whatever node chooses will affect the entire ecosystem, because node runs the tooling that the entire ecosystem uses. I want my package to be able to use ES 2015 features, and I want users of my package to not have to use a new enough node or browser that it supports them natively.

This argument is in no way weak. Package authors shipping a package that has both CJS and ES modules is the only way the entire ecosystem will remain compatible. Thus, every package needs to be "fat".

[martinheidegger]

@ljharb There is a difference between a package being fat at runtime and a package being deployed fat. In 5 fat packages are not just possible but also easy. The difference being that you specify the CommonJS parts of your package at deploy-time so they can be stored separately and fetched separately.
None of the proposals (not 2 and not 4 and not 6) are fat-by-default. Which means it is still probable for all cases that people make mistakes when publishing packages (Namely: put ES2015 code into a file that is detected as CommonJS or forget a fallback to CommonJS). Imho. 5 fares better in that regard to publishing because it is easier for the package developer to understand her actions.