Enhancing .npmrc support in Workspaces for use-node-version

[mark-omarov]

Hello everyone,

I've encountered an issue recently that might benefit from some brainstorming and discussion before opening an official feature request / bug report. This seemed like the perfect place for that, so here it goes:

The Problem:

I've identified a limitation with the current functionality of the use-node-version option in the .npmrc file of a package residing within a workspace. Currently, use-node-version is only acknowledged from the root level .npmrc, and any versions defined within the packages of a workspace are ignored. This becomes problematic when a workspace houses multiple packages requiring different Node.js versions.

To illustrate this, let's consider a scenario where a workspace has several packages with distinct Node.js version requirements. Given the current limitation, applying use-node-version imposes the root (or global) version onto all packages, which may not be desired.

I've also prepared a simple example to reproduce the behaviour here.

Desired Behaviour:

Ideally, I'd like to specify the exact versions for different packages. Furthermore, when executing from a workspace, I would like pnpm to adhere to these versions and execute scripts in each package using the version specified in the package's .npmrc.

This would bring seamless, per-project version switching without needing other tools and give an additional reason to use pnpm for hesitant ones. 😄

Potential Approaches:

After exploring the source code, I've found a couple of potential solutions that I can see at the moment:

1. Modify @pnpm/npm-conf to resolve the version from the individual package in a workspace instead of the workspace's root. Currently, the "workspace" and "package" sources within a workspace load options from the same .npmrc file in the root directory. It seems more intuitive for the "package" source within a workspace to read from the package's .npmrc instead. It seems to be the cleanest way at the moment, but it would likely require changes in the pnpm source code as well. Specifically, the use-node-version set in the pnpm/src/main.ts:273.

2. Enable pnpm to read .npmrc files from individual packages in a workspace environment and restructure the config to turn useNodeVersion into a hash table, with package names as keys and their corresponding node versions as values.

Additional Considerations:

We can execute workspace scripts within a workspace with the -w, --workspace-root. In cases where these scripts might execute package-specific scripts (perhaps applying the --filter), such use cases should also be supported.

Looking Forward:

I'm currently in the early stages of addressing this issue, and although I've contributed before, my understanding of the project is still developing. I would greatly appreciate the chance to discuss this further and explore the possibility of implementing this feature.

Looking forward to your thoughts and feedback. Thanks!

[mark-omarov]

Hi @zkochan, if you have a minute, could you please take a look? I'm really keen on hearing from you on this one. Cheers!

[zkochan]

hi, I have no objections

Enable pnpm to read .npmrc files from individual packages in a workspace environment and restructure the config to turn useNodeVersion into a hash table, with package names as keys and their corresponding node versions as values.

this is already used in recursive.ts at plugin-commands-installation, so I would go with this approach

[mark-omarov]

Great, I'm gonna give it a shot. Thanks!

[safejace]

i have just run into this issue. this would be a super helpful as i am trying to move a bunch of older apps into a new monorepo, and they all have different node versions.

[mark-omarov]

That was the case for me, I resolved it by upgrading all applications, but it's not always possible/necessary, nor I'd like to repeat it.
I am occupied with other things right now, but I'll try to get to this sometime soon, hopefully.

[Sh031224]

Every time a new node LTS is released, all packages in the monorepo must be updated.
For this reason, I think this is a very useful feature.

I found a pull request that has been closed about to this feature. ( #6724)

Are there any more updates?

[mark-omarov]

Hi @Sh031224 , I'm not working on this feature anymore, and it's unlikely I'll be back on it anytime soon.

[Sh031224]

I got it. Thanks for your reply.