r/node • u/GamingRohan71 • 5d ago
Would anyone actually use this? Building a compatibility layer for native Node.js dependencies
I've been working on an idea called Nexus, and I'd like an honest reality check from people who understand Node.js tooling, package managers, etc.
I started with trying to build "Conda for javascript" then realised that already existed and pivotted to
"When you switch Node.js versions, native dependencies may stop working. The common solution is to rebuild dependencies, potentially running rebuild/install scripts across a broad set of packages."
But not every native binary necessarily becomes incompatible.
The idea behind Nexus is to inspect native .node artifacts without executing them and derive their compatibility requirements.
Currently, the model distinguishes between things like:
- Raw V8 addons → require a specific Node ABI
- N-API addons → may remain compatible across Node versions if the runtime provides a sufficient N-API level
- platform/architecture constraints
So instead of:
Node version changed
→ rebuild everything
the eventual workflow would be:
Node version changed
→ Nexus analyzes native artifacts
→ identifies exactly which ones are incompatible
→ package manager rebuilds only those packages
I've already built a POC and tested the core idea against multiple Node runtimes and real native artifacts. But before investing much more time into it, I want to know:
- Is rebuilding native dependencies after switching Node versions actually a painful enough problem for anyone to care about?
- Would you trust a tool that statically analyzes
.nodebinaries to decide whether a rebuild is necessary? - Where would this realistically be useful: individual developers, monorepos, CI, Node version managers, package managers?
- Is there an obvious existing tool that already solves this problem properly?
- Would this be more useful as a standalone CLI, a library/API, or something integrated into pnpm/nvm/Volta/etc.?
- Most importantly: what am I missing, and is this a real problem or just technically interesting engineering?
Please be brutal. I'm specifically trying to determine whether Nexus solves a genuine problem before continuing to expand it.
3
u/Total-Basis-4664 5d ago
Long story short, feels like an awesome idea that is solving a non-issue.
1
u/duhniks 5d ago
Agree, it is cool, but I dont need it.
1
u/GamingRohan71 5d ago
Is there any modification of this idea that you would find useful? Or Is there any problem that you wish a tool would solve?
1
u/spidermonk 5d ago
You're not the only person who can now build tooling very quickly. Don't waste your time on ideas you don't have a direct personal need for.
1
u/duhniks 4d ago
I think my perspective have probably changed a lot in the last year. Because of the increasing number of and severity of supply chain attacks on NPM I have mostly stopped relying on NPM packages as a whole, and secondly, AI has made it easier than ever to just create whatever tooling I need for every project, or internally in my org. To me the risk of supply chain attacks is higher than the cost of just vibing internal dev tooling. And no, I dont read the code of those vibed tools anymore than I read the code of NPM packages.
1
u/GamingRohan71 4d ago
I see. I have thought of this perspective but I didn't realise how widespread it is now
6
u/jake_robins 5d ago
I haven’t particularly found rebuilding dependencies after Node upgrades particularly painful. I’d be wary of introducing third party tools that handles a job npm already does, especially in the world of insane AI supply chain attacks