Run correct npm completion script

[callumacrae]

I have the following line in my .bash_profile:

source ~/.nvm/v0.10.28/lib/node_modules/npm/lib/utils/completion.sh

That seems kind of fragile. Is there a better way, or could a better way be written?

[ljharb]

You could create an alias, and put the path to the alias in your bash_profile

[callumacrae]

That's just another way of doing the same thing though, right? If I use a different version of node, I'm now using the wrong completion.sh.

[ljharb]

Ah, i see what you're saying. You could do source ~/.nvm/node -v/lib/node_modules/npm/lib/utils/completion.sh which would adapt, but you're not going to re-source your bash profile every time you switch node versions. I'm not really sure what a proper solution is here.

[callumacrae]

Would adding a line to nvm use do the trick?

Link for if I do it: https://github.com/creationix/nvm/blob/master/nvm.sh#L462

[ljharb]

I don't think it's appropriate to handle shell completion inside nvm. I'd be open to a way to solve this, but I'm not sure what you have in mind to add to nvm.sh

[callumacrae]

Either through an option (--autocompletion?) or possibly just by doing something like adding a hook (if $NVM_USE_RAN points to a file, run the file), which would let people do it themselves. Not sure about the second one, though.

[jasonkarns]

How big of an issue is this, since the npm completion script mostly just calls out to npm completion (which would then be using the nvm-managed npm)? Would anything be improved if nvm used proper shims? (#577)

[ljharb]

The idea, I think, is using the nvm-managed npm whenever nvm switches node versions.

Shims don't actually end up improving anything, if Ruby's tools are any indication :-)

[wilmoore]

How big of an issue is this

This is really only an issue when switching between node versions that include wildly different npm versions.

This can be solved by simply using the latest version of npm always (regardless of the node version you are currently using).

I personally just do the following:

• export PATH=$NPM_CONFIG_PREFIX/bin:$PATH
• npm install npm@latest --global # this will install npm to $NPM_CONFIG_PREFIX/bin
• source <(npm completion)

If you've installed the latest npm but get an older version when you npm --version, then you have a $PATH order issue since there are multiple npm programs installed. You can debug through this by typing which -a npm then use that to fix your $PATH ordering.

[ljharb]

I don't have $NPM_CONFIG_PREFIX specified anywhere - where is this set for you?

I highly discourage anyone from installing anything outside an nvm version path. Each node/io.js should have its own copy of npm, and if they don't, I consider that an unsupported environment.

[wilmoore]

I don't have $NPM_CONFIG_PREFIX specified anywhere - where is this set for you?

$NPM_CONFIG_PREFIX is not set by default; but is honored by npm when set.

[ljharb]

Just like in #606, that's the sort of thing that nvm will forcibly unset in the future - those kinds of settings are fundamentally incompatible with nvm.

[wilmoore]

that's the sort of thing that nvm will forcibly unset in the future

Seems like a fairly rude thing to do :unamused: - What other modules should I be afraid nvm might intentionally break in the future?

[ljharb]

I haven't committed to doing that - I may instead just make it so nvm refuses to work if any of those are set (which is less invasive). nvm doesn't break modules - but non-default config options for npm are rarely a good idea anyways, but most of those options were designed for a world where there's only one node installed, so it's just not reasonable to expect them to work in a multiple-node world.

[wilmoore]

I may instead just make it so nvm refuses to work if any of those are set (which is less invasive).

Well, that would indeed be less terrible.

[andihafner]

On my Ubuntu 20.04 box with nvm 0.35.3 installed, there exists the environment variable

NVM_BIN="/home/[username]/.nvm/versions/node/v12.16.3/bin"

Therefore, a

source $(echo $NVM_BIN)/../lib/node_modules/npm/lib/utils/completion.sh

does the trick version independent.

[gotofritz]

It looks to me a very simple solution is being overlooked. All we need is the default command to create an alias to the default version. Just the same way pyenv has ~/.pyenv/shims/python which is always the same. So for example

/Users/gotofritz/.nvm/versions/node/default -> /Users/gotofritz/.nvm/versions/node/v17.3.0/bin

I called it default but of course it can be called shim, node, or whatever

So in my scripts, when needed, I can link to /Users/gotofritz/.nvm/versions/node/default/node regardless of what version is currently the default. It shouldn't be that hard to do, I will try and submit a PR as soon as I get the chance. WDYT?

For the record, my use case is creating worfklows for Alfred App on OS X, which is fussy about these things and requires an absolute path to the node executable

[ljharb]

@gotofritz that is very much not a solution at all. nvm is a per-shell version manager; the entire way it works is by changing the PATH, and it is a category error to try to have one single system-wide version of node with nvm.

nvm used to have a estuve like this, but it was removed for breaking too many workflows. I’m going to hide your comment, since it’s off topic for this particular issue.

[gotofritz]

But what are ~/.nvm/alias/default and $NVM_BIN if not user-wide (not system-wide) defaults...? Regardless, I see you don't like the idea, we'll have to agree to disagree there, I'll find another way. Thanks for the tool anyway

[ljharb]

@gotofritz default is a systemwide alias that could change at any time, and when changing won’t affect anything previously established from it. NVM_BIN is a shell-specific env var, and is not systemwide in any way.