Need RFC for npm/yarn link between projects with conflicting node versions

[jimmyhchan]

How should notion behave for the npm link usecase?

Imagine project A uses node@6 and project B uses node@8 with project B depending on A

The workflow used would be:

1. cd projectA
2. npm link to make it globally available
3. cd projectB
4. npm link projectA to link it up.

The npm versions used in 2 and 4 are different and will cause B not to find A

[benblank]

I know that nvm, in this scenario, offers no solution — projects must be using the same version of Node in order to link them in this manner.

[jimmyhchan]

the engines stanza of package.json supplies enough information for a tool to make this work automatically. For the example above, if Project A states use node:6 but also states it supports >4 <=8 and if Project B states use node: 8, notion could magically call npm link using node 8.

IMO, the feature of notion to automatically switch to the version in the current project, implies it should also "do the right thing" when npm linking.

[stefanpenner]

I believe making npm link cross node versions work transparently may want to be outside of the scope of notion. As this behavior is npm / yarn specific, and important for several reasons. such as to avoid linking across incompatible ABI's (an issue when dealing with native dependencies).

My preference handle this scenario would be to add a CLI option to notion which overrides the ambient configuration for the current session/command, in an ephemeral way.

Some potential 1-off commands:

// in projectA
notion set node@8 // only updates ENV vars, notion, to disk
// or
notion set --save node@8 // updates env vars
// or
notion run node@8 -S npm link

[charlespierce]

See also #657 for an additional use-case of npm link that we should support (or explicitly document that we don't support).

[serapath]

in #657 i tried to think about a solution.

if you maintain a list of all linked modules, wouldn't it be possible to update all symlinks whenever node versions switch?

[charlespierce]

@serapath The issue is that Volta doesn't necessarily know about node version switches. For instance, if a project has its version changed as part of a git pull operation, we wouldn't be aware of that until the first command was run. Or changing directories between projects that are pinned with different versions.

It's something we could potentially look for, but we would need to evaluate whether the benefits were worth the additional checks that would be needed on every execution

[serapath]

I like volta because it allows me to install and manage node versions across platform.
How many ways exist to switch node?
Doesn't volta anyway check every time a directory changes?

Would it work to just check which node and watch it?
Either that file changes or when directories change, maybe the which node shows a different target

...anyway, i think having that under control across platform would be an amazing goal for volta :-)

[charlespierce]

We definitely want to have a story for link that works across different platforms, as much as possible.

Volta doesn’t actively track / watch anything, instead the way it remains context-aware is that it sets up shims for each of the tools and evaluates the correct node version on each execution.

[charlespierce]

With #888, we now have real support for npm link, including making bin tools available when you link a local project. For the case of cross-node versions, when we have all the information to detect the issue, we show a warning to the user letting them know that the versions don't match and things may not interact as expected.