Refactor: convert to ESM module (.js files)

[mhegazy]

• var mod = require('mod'); =>

  • if mod is callable then import mod from 'mod'
  • else mod is not callable the import { a, b } from "mod" and replace mod.a and mod.b
  • namespace import should ever be used?

• 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") to require("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

• module.exports = require('mod'); => export * from 'mod';

• module.exports = {foo: function () { } ... } => export function foo() {} ?

  • is this even common enough to support?

[aluanhaddad]

Of the last two, perhaps the first should be

module.exports = require('mod');
    // => 
       export * from 'mod';
       export {default} from 'mod';

since the export * should exclude default.

And perhaps the second should be

module.exports = {foo: function () { } ... };
    // =>
        export default {foo: function () {}};

as, if the module is consumed natively as an ESM by a NodeJS ESM, the named export foo would not be available at all otherwise.

[ghost]

@aluanhaddad I think export * already includes all exports? At least TypeScript treats it that way.

[aluanhaddad]

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.register transform also behaved differently the last time I checked.

[ghost]

Just tested with .mjs and it looks like you're right and default isn't brought along. @rbuckton Can you confirm that this is the correct behavior? Should TypeScript be catching that error?

[ghost]

@aluanhaddad Can you clarify what you mean by the second comment? If I write export function foo() {} I can access it from a .mjs file just fine with import { foo } from "./a";.

[aluanhaddad]

Can you clarify what you mean by the second comment? If I write export function foo() {} I can access it from a .mjs file just fine with import { foo } from "./a";.

Yes, I did not mean to imply otherwise. All exports (except the default export if present) are reexported by export * from "m";

Here is the specification text that describes the default exclusion.

https://tc39.github.io/ecma262/#sec-getexportednames

See section 7.c.i

[ghost]

By second I meant the one starting with And perhaps the second should be.

[rbuckton]

@aluanhaddad is correct, default is excluded from re-exports using export * from ... syntax.

[aluanhaddad]

@Andy-MS

By second I meant the one starting with And perhaps the second should be.

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 the default export instead of creating named exports.
I'm not sure about this since it depends on how the imports are transpiled if at all.

module.exports = {foo: function () { } ... };
    // =>
        export default {foo: function () {}};