Closed TrySound closed 5 years ago
Looks like interpret
worked around the esm
funkiness. Checkout the readme here: https://github.com/gulpjs/interpret
e.g.
'.esm.js': {
module: 'esm',
register: function(hook) {
// register on .js extension due to https://github.com/joyent/node/blob/v0.12.0/lib/module.js#L353
// which only captures the final extension (.babel.js -> .js)
var esmLoader = hook(module);
require.extensions['.js'] = esmLoader('module')._extensions['.js'];
},
},
IMO all tools should provide it out of the box like ava does. It's not some random loader. Currently esm is the only spec compliant way to provide modules syntax in node. I'm sure in a lot of cases uses will be happy to "just use" import/export instead of commonjs.
And I'm sure users will not be happy to install one more package and add extension to config just to enable this syntax. It should work for free.
And this loader is almost free. Startup time is incredibly fast.
It's a philosophical debate between packing things a small number of users might need by default versus keeping a package lean and adding weight only when necessary. I trend toward the latter. Webpack tends to suffer because it trends towards the former.
In this case I have to insist on following the established pattern and using rechoir
to add esm
as a loader. If a user needs esm
for a project then chances are better than average they already have it installed. Same as for the other loaders.
Ok, added esm via rechoir. Though I still think it should be default to move community forward.
This PR contains:
Breaking Changes?
If yes, please describe the breakage.
Please Describe Your Changes
ESM is a great tool to support modern modules out of the box. In this diff I enabled it only for simple .js extension to not conflict with babel and typescript loaders (though I'm sure they will work fine).
Implementation was simpler than I expected.