One lesson I’m taking away from the axobject-query incident: there isn’t a formal agreement about which npm packages are isomorphic JavaScript friendly (intended for both client & server).
Notably the `browser` key in package.json is documented as to be used *instead* of `main` (not both): https://docs.npmjs.com/cli/v10/configuring-npm/package-json#browser (and axobject-query does not use `browser`)
Assuming that packages are client bundle friendly without tacit agreement from the maintainers of those packages is perilous!
17 replies
The other lesson here is in the real consequences of maintainers (even those with a small following) airing small dev grievances on Twitter (Svelte/SvelteKit in this case).
The parasitically harmful YouTube JavaScript influencer ecosystem feeds on small drama like this, resulting in elevated abuse toward well-intentioned maintainers—pretty gross all around.
@zachleat Totally agree with this take. Hopefully we'll get better
The algorithm fueled pile-ons have been getting much worse.
Taking up farming sounds more appealing by the day…
@zachleat You're onto something here.Also packages that explicitly require bundlers.
I promise I'm not here to air more small dev grievances, but on a sister repository I was told that the proper way to ship libraries is untranspiled CJS.
Which gets back to your point of "is this package intended to run in a browser" and "can this run without a compilation step or Node polyfills etc"
(For reference)
https://github.com/A11yance/aria-query/pull/485
NPM needs some tags!
@zachleat The other problem when you "make these agreements", is usually someone else has also made the agreement for you, making it even harder to track down.
In the "aria-query" example, its a dependency of dom-testing-library, and I hit the issue while using react-testing-library, which relies on dom-testing-library, which relies on aria-query
-
@McNeely it’s not worth it 😬
@zachleat this has been soo weird to me, and *particularly* since Wasm came about and people started compiling JS engines to Wasm (for small embedded scripting systems & for sandboxing). While "systems" languages like Rust has a notion of std/nostd to cater for embedded & Wasm and a ton of other usecases the best we got is WinterCG but otherwise the JS ecosystem likes to pretend every script still runs in Netscape Navigator 4.0 and there aren't like 796 different embeddings of V8 and a 100 other JS engines and runtimes in mobile apps, the cloud, the edge, in space suits and bloated desktop apps...
@flaki “the JS ecosystem likes to pretend every script still runs in Netscape Navigator 4.0” that doesn’t resonate with my experience—do you think this is a widespread thing or just this one person?
@zachleat I'm sure part of the (source of the) problem is the "I cannot possibly know of and/or cater for every runtime and every usecase" which is a hard ~~computer~~ social problem to solve, particularly for OSS "provided as is and without fitness for any purpose" etc., and while above I've certainly been exaggerating somewhat, I more meant it in that JS still can't or doesn't want to recognize just how widespread/abundant it is, and while individual devs can argue that they shouldn't be required to support every use case (the certainly needn't!), centrals gatekeepers such as npm has been excruciatingly slow to react to this diversification...
(part of the reason, of course, is *having* central gatekeepers like npm in the first place, but while I really like e.g. Deno's approach where Ryan & co tried to fix this particular mistake, it's a mistake we're likely stuck with for good...)
@flaki ah, yeah—that makes more sense. Certainly “JS still can't or doesn't want to recognize just how widespread/abundant it is.”
I don’t think I agree that centralization is the root problem though. I don’t see Deno fixing this either. I see something like Google’s Baseline as a path forward here—each package needs to declare it’s intended use and compatibility.
@zachleat TIL Baseline! Which feels like it's for the web what is https://wintercg.org for edge/cloud/embedded. Maybe with time we will have more standards (and more standard recognition/tooling) for this, and I agree that would get us into a whole lotta better place.