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.
-
-
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 -
One easy win for FE devs on npm would be to officially adopt the browser field spechttps://github.com/defunctzombie/package-browser-field-spec …
2 replies 0 retweets 6 likes -
What would "officially adopting" look like?
1 reply 0 retweets 0 likes -
I think just including it in the package.json docs and/or linking to it https://docs.npmjs.com/files/package.json …
2 replies 0 retweets 6 likes -
It's tricky because package.json has evolved beyond the needs of npm. But this one field in particular has served the FE community well
1 reply 0 retweets 3 likes -
Took the liberty to spend a minute
https://github.com/npm/npm/pull/18382 …2 replies 0 retweets 13 likes

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.