…interesting to me how heavy the browser representation here is, given the meta-npm tooling for using npm libs in browser is such a mess
-
-
Replying to @mcclure111
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.
2 replies 0 retweets 8 likes -
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 -
Replying to @wycats @mcclure111
If there are thing npm could do today to improve FE that are practical for our team of 18 engineers, I am all ears.
4 replies 0 retweets 3 likes -
Replying to @seldo @mcclure111
For me, a lot of what's tricky about FE tooling is the rough edges around introspecting node_modules.
2 replies 0 retweets 0 likes -
For example, require.resolve gives you the main file, but it's not always in the root. These issues are ancient and wontfixed.
1 reply 0 retweets 0 likes -
Maybe there's already a nice npm-maintained package floating around that gives you a graph of node_modules in consumable form?
3 replies 0 retweets 1 like
(for context we've been working on extracting https://github.com/tildeio/libkit lately so many of the issues are fresh in my mind)
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.