[addicted]

Let’s flip this.

What are the advantages of ESM that led to selecting that over CJS modules for standardization in the first place?

[Ginden]

Statically analyzable tree. In CJS you have to depend on people not doing strange things to their `module.exports` and you are left with heuristics.

[joepie91_]

This is not actually a meaningful benefit that ESM has in practice, as I've explained in my article.

[lucideer]

> as I've explained in my article

Not convincingly.

Firstly, static imports are markedly different to top-level require due to module scoping: e.g. tree-shaking isn't stable with most "statically-analysed" top-level requires due to potential side-effects.

Secondly, handwaving dynamic imports as the ES Modules equivalent to non-top-level require doesn't pass the smell test. Dynamic imports are a deliberately separate syntax and mechanism to static imports, whereas require isn't differentiated. They are also, notably, async.

[wruza]

Smell tests are irrelevant to analyzers code. Developers are either able to break analyzers by using import() or are unable. They’re still able with ESM, and they’re still able to deliberately not do that with require(literal). Async has nothing to do with that, all it does is wrapping T into Promise<T>. No notable difference for static checks, promises are everywhere in javascript.

[wruza]

Could you please point to “strange things” that people do with “exports” AND how it prevents static analyzers from doing their job? Why they can do it for:

  var x = strange_thing()

but suddenly can not when “x” is renamed to “exports”?

[Ginden]

Eg.

    module.exports = {foo: 3};
    setImmediate(() => module.exports[Math.random() > 0.5 ? 'foo' : 'bar'] = 5);

This is impossible for ES modules, because exports are static and known at parse time.

Few widely used packages do something like:

    enhanceWithAdditionalProperties(module.exports, mixin);

[wruza]

Not the same but similar:

  export var foo = 3
  setImmediate(() => {foo = Math.random()})

Under ESM, exported values are still not known at parse time, and may be changed by the library (but not created nor deleted). And given that exported may be changed, what prevents library makers from doing:

  export default var exports = { }
  enhance(exports, mixin)

and you are left with heuristics again?

I see these subtle differences, but fail to see how they are a solution to the problem of “doing strange things to exports”.