Agreed. We are very aware of this problem but can only fight so many fires, and the tooling, while complex, is at least solving the problem.
-
-
Replying to @seldo @mcclure111
I don't understand this logic. It seems better to work on the thing used by a majority, but hey, the mess keeps me busy.
1 reply 0 retweets 2 likes -
Replying to @wycats @mcclure111
By "we" I mean npm Inc. We are trying to keep the registry afloat and improve npm's core; improving webpack is out of scope for now.
2 replies 0 retweets 6 likes -
Replying to @seldo @mcclure111
I don't think npm should improve webpack (wouldn't help Ember), but there are things npm could do to make things generally better for FE.
4 replies 0 retweets 7 likes -
Some (a lot?) is on node core and the modules story. The .mjs proposal is going to wreak havoc on the FE ecosystem, which uses .js for years
2 replies 1 retweet 7 likes -
For non-webpack users*** We should be okay regardless
3 replies 0 retweets 0 likes -
Replying to @TheLarkInn @wycats and
Well, webpack cheats by just ignoring the loader semantics and hand waving commonjs interop.
2 replies 0 retweets 1 like -
Replying to @jankrems @TheLarkInn and
And? I haven't seen any complaints from users of webpack over how esm is compiled. Perhaps TC39 should take a hint.
2 replies 0 retweets 0 likes -
Replying to @probablyup @TheLarkInn and
Maybe not from webpack users. But it *is* a problem once you want to run the same code natively using actual runtime semantics.
1 reply 0 retweets 2 likes -
Replying to @jankrems @TheLarkInn and
"Native semantics" is a runtime impl detail that normal people don't care about. As long as things run in order it's not an issue
2 replies 0 retweets 0 likes
ES semantics are actually very limited. Just "assume we have the modules and then run them in order" + import/export linking.
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.