At most, it makes it marginally easier to implement export tracking in a tool, given the non-aliasable keywords. But given that tool implementation is a one-time cost, this is hardly an argument for migrating an entire ecosystem.
-
-
Replying to @joepie91 @slightlylate and
Common uses of CJS are tree-shakeable, but I believe there are myriad edge cases where it breaks down.
@Rich_Harris would know more. Of course you could just decide to use a subset of CJS, along with tree-shaking plugins that assume likewise. Or...you could just use standard ESM1 reply 0 retweets 1 like -
Replying to @AdamRackis @slightlylate and
Correct, there are edge cases. Those edge cases are the precise same cases that are unrepresentable in ESM (at least without using dynamic import, which you can't easily tree-shake for the same reason). Ergo, the module system used *does not affect* tree-shakeability of code.
1 reply 0 retweets 0 likes -
Replying to @joepie91 @AdamRackis and
The reason those edge-cases are not tree-shakeable is because they're not (easily) statically analyzable, or outright dynamically determined. It's that dynamic-ness that makes it not tree-shakeable, independent of the representation.
1 reply 0 retweets 0 likes -
Replying to @joepie91 @AdamRackis and
A much bigger issue is the lack of serious reusable analysis tooling for JS; driven in part by the relative monolithism of Webpack and Rollup. We could be eliminating *way* more code if we didn't limit ourselves to 'export surface', but there's no tooling for it, it seems.
1 reply 0 retweets 0 likes -
Replying to @joepie91 @AdamRackis and
So instead of trying to push ESM usage (which doesn't affect tree-shakeability in the end), a much more important thing to push for is a) better analysis tooling, that is b) independent from any one specific bundler.
2 replies 0 retweets 0 likes -
Replying to @joepie91 @slightlylate and
This makes no sense. The number of front-end libs that do not tree-shake bc of CJS, but do once they're converted to ESM is high. Really not sure why people think a non-standard, made-up module system is worth hanging onto for front-end dev when we have standards-compliant ESM
1 reply 0 retweets 0 likes -
Replying to @joepie91 @AdamRackis and
For one thing, Node modules aren't actually CommonJS (they don't adhere to the CommonJS 1.1 spec, which among other things forbids reassigning module.exports). But Adam is right — I've seen plenty of stuff like `var api = exports; http://api.foo = ...` which defeats SA
3 replies 0 retweets 3 likes -
Replying to @Rich_Harris @joepie91 and
I agree with all of this. It wasn't an accident:
@littlecalculist was interested in enabling this kind of statically analysis in tooling literally from the beginning of the proposal that eventually became ESM. It was a core constraint and panned out beautifully.1 reply 0 retweets 8 likes
The fact that you can use the restrictions in ESM to identify a subset of node's modules that work caveat-free and build a translation layer is a huge victory for the approach in ESM, not evidence that CJS was fine all along.
-
-
Replying to @wycats @AdamRackis and
Sven Slootweg Retweeted
I refer you to: https://twitter.com/joepie91/status/1040410830590947328 …
Sven Slootweg added,
This Tweet is unavailable.1 reply 0 retweets 0 likes -
(In particular to the part where this analysis complexity needs to be brought in *anyway* to eliminate dead code beyond the exports surface... which curiously is a point that everybody has been dancing around and not addressing so far.)
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.