This repository was archived by the owner on Sep 2, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 2, 2023. It is now read-only.
Feature: Dual-goal packages #93
Description
- I want to publish a package that can be imported as native ESM or required as CommonJS.
- I don’t want to need to transpile or have a build step in order to create such a package.
- I want to be able to use either ESM or CommonJS within my package.
- I want to be able to gradually convert my package from CommonJS to ESM.
Use cases 2, 10, 39, 41.
Activity
GeoffreyBooth commentedon May 20, 2018
I had a idea about how to achieve this, for the use case where my package is already fully migrated into ESM syntax. So the easy way, that doesn’t fulfill all the goals of the feature request, would be to have my app include a build step that transpiles it into CommonJS. The CommonJS version is what I publish to NPM and have
package.jsontell other packages to import. That’s what people do today.So how to achieve this without a build step? Well, what if we borrow some ideas from #81 and #101 and nodejs/node#18392 and https://github.com/rollup/rollup/wiki/pkg.module?
package.jsonwould have amainkey that points to a CommonJS entry point, and amodulekey that points to an ESM entry point (or other key names to be decided upon).mainCommonJS entry point would have something likerequire('babel/register')and then wouldrequirethe ESM entry point. This would allow my package to be imported by legacy versions of Node that lack ESM support, without the code being transpiled ahead of time.moduleESM entry point would be used by modern, ESM-supporting Node, and would bypass themainentry point (which is essentially just an ESM polyfill).The polyfill in the CommonJS entry point doesn’t need to be Babel, and it doesn’t (necessarily) need to transpile, if other solutions can be found. But let’s say that at least the above approach works. The downside of this is that for non-ESM-supporting runtimes, whatever the polyfill is (transpilation, etc.), it’ll surely be slower than if we had transpiled the package ahead of time and published it as native CommonJS. That’s the disadvantage of polyfills in general. But as ESM support becomes more common, this performance hit for legacy runtimes will become less important.
devsnek commentedon May 20, 2018
you can just do
main: 'src/index'and it will pick upsrc/index.mjsfor esm andsrc/index.jsfor cjsGeoffreyBooth commentedon May 20, 2018
I would prefer to have two keys and drop
.mjs.ljharb commentedon May 20, 2018
@GeoffreyBooth two keys doesn’t address deep paths; mjs will be necessary for ensuring that all files can be consumed by all consumers.