undefined | Better HN

0 pointsGinden4y ago0 comments

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.

0 comments

joepie91_4y ago

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

lucideer4y ago

> 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.

wruza4y ago

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.

wruza4y ago

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”?

GindenOP4y ago

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);

wruza4y ago

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”.

j / k navigate · click thread line to collapse

0 comments

joepie91_4y ago

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

lucideer4y ago

> as I've explained in my article

Not convincingly.

wruza4y ago

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”?

GindenOP4y ago

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);

wruza4y ago

Not the same but similar:

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

  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”.

j / k navigate · click thread line to collapse