Open dantman opened 6 years ago
This is a an awesome ticket and example, thank you for taking the time. I'm not focusing much effort on this library at the moment since the decorator spec is still in flux and babel doesn't yet have support for the new spec. Of course if someone else is interested in fixing this they can, but I unfortunately don't have the cycles to prioritize. 👍
Node has implemented native support for ES2015 modules with an
.mjs
extension. True modules that function according to the spec.One limitation of the spec differences between real ES modules and CommonJS modules is that imports from CommonJS modules cannot use named imports, the entire
exports
/module.exports
object is just exposed as thedefault
export.For core-decorators this results in the following: https://github.com/dantman/core-decorators-esm-test
You cannot
import {autobind} from 'core-decorators';
inside of ESM code. Your only option is toimport CD from 'core-decorators'; const {autobind} = CD;
.To make it possible to use named imports from core-decorators I think it would be a good idea to support Node 10's ES modules.
Doing this should be pretty simple for core-decorators, as core-decorators is a leaf package (a package with no dependencies). We just need to export another build in the package that uses ES modules like
es/
does but uses the.mjs
file extension. Also ESM modules use the samemain
as normal Node modules, you just specify main without an extension and Node 9- will get your CommonJS .js and Node 10/--experimental-modules
will get the ESM.mjs
. So either the.mjs
build will need to be inlib/
or you'll need anindex.js
andindex.mjs
in the package root to switch betweenmodule.exports = require('./lib');
andexport * from './esm';
.Given how ESM works, I think the ecosystem would adapt to ESM easiest if leaf packages like core-decorators are the first to support ESM. (Then packages with dependencies on leaf packages don't need to worry about importing CommonJS versions of leaf packages)