Repository navigation
Refactor: convert to ESM module (.js files) #19719
Description
-
var mod = require('mod');=>- if
modis callable thenimport mod from 'mod' - else
modis not callable theimport { a, b } from "mod"and replacemod.aandmod.b - namespace import should ever be used?
- if
-
var mod= require('mod').a;=>import { a } from "mod"; -
const { a } = require('mod');=>import { a } from "mod"; -
if (__DEV__) { var warning = require('warning'); }- disallowed?
- have two actions? one sync and one async?
-
function f() { var warning = require('warning'); }=>async function f() { var warning = await import('warning'); }- maybe do nothing here as well
-
module.exports = EventPlugin;=>export default EventPlugin;
- fix imports in other files
- should we also fix
require("mod")torequire("mod").default?
-
module.exports.blah = 0=>export const blah = 0- should we support this too
var myModule = module.exports = exports = {}; myModule.a = 0; - this is another common pattern in CJS modules that we should consider supporting
- we already have handling for this in the binder in .js files
- should we support this too
-
module.exports = require('mod');=>export * from 'mod'; -
module.exports = {foo: function () { } ... }=>export function foo() {}?- is this even common enough to support?
Activity
aluanhaddad commentedon Nov 7, 2017
Of the last two, perhaps the first should be
since the
export *should excludedefault.And perhaps the second should be
as, if the module is consumed natively as an ESM by a NodeJS ESM, the named export
foowould not be available at all otherwise.aluanhaddad commentedon Nov 10, 2017
I don't believe that's always the case. It doesn't appear to be true for Babel's
CommonJS output and TypeScript's
System.registertransform also behaved differently the last time I checked.aluanhaddad commentedon Nov 10, 2017
Yes, I did not mean to imply otherwise. All exports (except the
defaultexport if present) are reexported byexport * from "m";Here is the specification text that describes the
defaultexclusion.https://tc39.github.io/ecma262/#sec-getexportednames
See section 7.c.i
rbuckton commentedon Nov 10, 2017
Aluan Haddad (@aluanhaddad) is correct,
defaultis excluded from re-exports usingexport * from ...syntax.aluanhaddad commentedon Nov 10, 2017
Andy (Andrewkraft) (@Andy-MS)
Ah, sorry, my brain kind of went to sleep for a second 😪.
I meant that since Node.js is not yet supporting named exports, unless something has changed, and since this concerns a refactoring transformation that might be output using
--module es2015, it might make sense for the refactoring to place properties on thedefaultexport instead of creating named exports.I'm not sure about this since it depends on how the imports are transpiled if at all.