Now that I got used to pnpm and yarn, as well as monorepo tools (nx), I feel like my preference would be to continue improving npm and node without forking.
I mean, there's yarn, pnpm and other package managers.
Then there's alternate JS runtimes, e.g. Deno or Bun.
Both of which are primarily interesting to me because of first-class TS support without transpiling.
I feel that the ideas of all these same-but-different approaches are in dire need of a shared roof and efforts on standardization and interoperability.
Not sure if corepack[1] is a step in the right direction, because it basically adds another abstraction layer on top of the runtime to choose and install the package manager...
All of the mentioned tools bring laudable and serious effort to the table, but I'd love for convergence to happen as soon as possible.
I care a lot about using great tools, but I agree. The thought of having to hold another widely adopted backend JS runtime in my head to be an effective ecosystem developer is not pleasant. I would rather spend that concentration thinking about tools that complement JS/NodeJS in massively more meaningful ways, like Golang or Rust.
I have a tremendous amount of respect for the Deno team, their point of view, and what they have done and continue to do. In an alternate reality, maybe everyone would be happier if they had displaced NodeJS. (I don't know.) But from my point of view in the trenches, seriously imagining the widespread adoption of another major NodeJS-incompatible runtime (the browsers are bad enough!) is almost depression-inducing. I just finished migrating my monorepo source code to ESM (except for the lingering .cjs config files for commonjs-only dependencies). Holy hell, did that make me long for Laravel. It does not have to be this way. Enough already.
NX is a double-bladed lightsaber. I love it when it is working. The problem (and I say this with appreciation for the difficulty of the task) is there are too many bugs. Bugs in your monorepo tooling are scary and dangerous, especially for young or lower-maturity shops without very comprehensive QA.
A few months ago, I managed to get all the way to final production artifact verification on an iOS app after a casual NX upgrade and multiple major monorepo-level commits to discover that the "fileReplacements" configuration for the application environment variables had stopped working. Boy did that ever stress me out, because that would be a disaster to release, and it is so low in the tooling stack that you can be lulled into expecting that sort of thing to just...work because the team supporting it understands the consequences of a breakage in that sort of functionality. This is the type of bug that results in incidents that developers write their "it-finally-happened-to-us" blog posts about. I mention this because it was a particularly memorable incident for me, but there have been other bugs that were less dangerous and more just unpleasant, but any failure to properly compute affected packages in a production build could get very gross. This feels like a memory, but it might just be a fear.
I still voluntarily keep NX and like a lot of things about it. The engineers seem to care a lot and have made some impressive features. But I stay on my toes, and my attitude has shifted away from excitement about the latest-and-greatest to a focus on keeping my options open and minimizing lock-in.
It feels like the NX decision-makers are trying to do much, too quickly. They are building and releasing with notable speed. How many production releases are there for each NextJS production release? And NX is at a lower level of the tooling stack, with a far broader range of integrations. I state that merely as an off-the-cuff anecdotal observation, not as some greater opinion on release cadence. But this does feel like "a more releases, more bugs, wrong area of the tech stack for that" type of situation.
Re nx, i can't tell if it has improved since 2 years ago, but i feel it being an inconvenient abstract layer at times;
OTOH: I rarely encountered nx-specific issues at work, and all of them have been caching-related.
It's mostly doing well at organizing a monorepo with lots of code in different languages.
Just recently I saw something in this direction.. Ah yes, here it is.
WinterCG - Web-interoperable Runtimes Community Group
> This community group aims to provide a space for JavaScript runtimes to collaborate on API interoperability. We focus on documenting and improving interoperability of web platform APIs across runtimes (especially non-browser ones).
I see Cloudflare, Deno, Node.js, Netlify, Vercel. I guess Bun hasn't joined yet, but they seem to be intentionally implementing web-compatible interfaces.
Now that I got used to pnpm and yarn, as well as monorepo tools (nx), I feel like my preference would be to continue improving npm and node without forking.
I mean, there's yarn, pnpm and other package managers.
Then there's alternate JS runtimes, e.g. Deno or Bun. Both of which are primarily interesting to me because of first-class TS support without transpiling.
I feel that the ideas of all these same-but-different approaches are in dire need of a shared roof and efforts on standardization and interoperability.
Not sure if corepack[1] is a step in the right direction, because it basically adds another abstraction layer on top of the runtime to choose and install the package manager...
All of the mentioned tools bring laudable and serious effort to the table, but I'd love for convergence to happen as soon as possible.
^1
https://nodejs.org/api/corepack.html