How to update nvm

[Pana]

If nvm has a command that will update himself, it will be more awesome. Now the method i know is remove nvm and reinstall, but this will set all my node reinstall

[creationix]

I always install by cloning from git. Then if I want to update, I simply do a git pull.

That said, why would you upgrade if it's working? Personally I've never upgraded nvm after installing it on a machine. (though my operating system install lifetimes are fairly short). If you learn about a new feature that you need, then git pull and you're done.

Remember that every feature added has a cost. Could you explain what exactly makes it more awesome? Perhaps I'm not understanding your use case.

[ljharb]

Duplicate of #127

[ljharb]

Also, you don't have to ever remove nvm - just install the newer version, and it will replace the older one.

[mgol]

I feel #127 shouldn't be closed now that users are not supposed to run from master but from a tagged commit. I use the following script:

#!/bin/sh

set -e

cd ~/.nvm

git fetch --tags
TAG=$(git describe --tags `git rev-list --tags --max-count=1`)
echo "Checking out tag $TAG..."
git checkout "$TAG"

source ~/.nvm/nvm.sh

[chrisspiegl]

+1

[pcriv]

+1

[dead-claudia]

It appears that simply effectively re-installing over an existing nvm actually updates it. This would be a really trivial script.

[dead-claudia]

I believe this should do it. The $@ is optional, but mostly for debugging (Depends on either curl or wget, preferring the former.)

#!/bin/sh

download() {
  if which curl > /dev/null; then
    curl -s $@
  else
    wget -qO- $@
  fi
}

download https://raw.githubusercontent.com/creationix/nvm/v0.20.0/install.sh | /usr/bin/env bash $@

Or, if you'd prefer a giant one-liner, here it is. This one should also work with csh, although I don't have one installed to test with. It's probably the most portable. It is alias-safe if you drop the last $@, but make sure to use double-quotes.

#!/bin/sh
`which curl > /dev/null && printf 'curl -s' || printf 'wget -qO-'` https://raw.githubusercontent.com/creationix/nvm/v0.20.0/install.sh | /usr/bin/env bash $@

Both have been tested in dash and bash, and they should be fairly portable, even with older shells.

If you want to add support for using Git, it'll take bit more logic and a lot of Git "plumbing" commands, such as git ls-remote -t https://github.com/creationix/nvm.git (lists commits and tags, but former needs filtered out). Long story short, it's far from trivial.

Maybe that could be put into nvm.sh somewhere.

[ljharb]

It's trivial for a user, because you already know your preferred installation method.

However, nvm can be installed via curl, wget, git clone, or even simple file copying. It is in no way trivial to include in the actual product.

The only current blessed way to install and update nvm, is the ones I've mentioned - and I strongly encourage the curl command in the README on the git tag for the latest release.

[dead-claudia]

You could probably do something similar, just retrieving the current version first, and then the install script similarly. Mine tries the curl method first (fixed to be silent like wget).

[xfq]

@mzgol

Thanks for your script! I have two questions about it:

1. Can I run this script in a shell that has run source ~/.nvm/nvm.sh before? I mean, is there any side-effect in nvm.sh (that may cause problems if nvm.sh is run more than once)?
2. Do I have to install Node.js again after updating nvm? IIRC Node.js is installed exactly in the ~/.nvm directory.

[ljharb]

@xfq nvm unload will completely unload nvm from the shell, so even if it wasn't safe to re-source (it is), you could unload it first if you wanted.

[xfq]

@ljharb I see. Thank you. What about the second question?

[ljharb]

You shouldn't need to reinstall any node versions after updating nvm, no.

[surfjedi]

I have just tried reinstalling NVM -
Lees-MacBook-Pro-2:~ leeblazek$ curl https://raw.githubusercontent.com/creationix/nvm/v0.23.0/install.sh | bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5205 100 5205 0 0 17370 0 --:--:-- --:--:-- --:--:-- 17408
=> nvm is already installed in /Users/leeblazek/.nvm, trying to update
=> Lees-MacBook-Pro-2:~ leeblazek$

But it just doesn't seem to do anything? I have also tried sudo, but still the same non-result

Any ideas?

[ljharb]

@surfjedi This was reported in #559 (comment) - can you try METHOD=git . install.sh and see what happens?

[evenfrost]

@ljharb I faced same problem as @surfjedi, and running METHOD=git . install.sh helped, thanks.

[andrew-aladev]

@ljharb, I don't know what you mean unsafe.

I have a good source code, covered with unit tests and more complex tests. I want now to prepare the next version of container with nvm, node:lts and test it in automatic mode. If it will fail I will dive into container and fix it. My Dockerfile wants script for installation of latest nvm. I am opening nvm readme and I can't find this command.

I can't move to fnm because I am using nvm install "$(cat .nvmrc)" --reinstall-packages-from="$(nvm current)" and I like it.

I am sure that its an issue. I see no reason why readme has no command for installation of latest version. Your command for installation of fixed version may be first one and installation of the latest version mey be the second one.

[ljharb]

It's unsafe because it's not reasonable to assume that anyone - let alone everyone - has tests covering usage of nvm commands which are often typed by devs, or in CI/build scripts that aren't themselves tested.

[andrew-aladev]

So your plan is the following:

1. CI/build scripts includes abandoned version of nvm.
2. Script launches install lts/* but it can't install the most recent lts version, it installs some lts version.
3. Script won't fail, but project won't receive the recent version of lts node.
4. Script is more important that project.

[ljharb]

I'm not following your logic. If ANY nvm command would stop working, then it's an unsafe update to receive blindly. This is the same reason why a node project should never use * or latest or >= or >, only a semver range using ^ or ~ or =, to depend on a package.

[andrew-aladev]

If ANY nvm command would stop working, then it's an unsafe update to receive blindly.

Ok, you are talking now with this developer, that wants to update system somehow. I am implementing Dockerfile.staging with some blind or not blind update. Dockerfile may include fixed version, but Dockerfile.staging will include recent version of nvm. Dockerfile.staging won't be included in release.

Can you please include a line into readme with installation of recent version of nvm for such developers?

[ljharb]

The line is the one with the explicit version. You're expected to copy and paste the line any time you want to install the latest version, and be aware of the caveats yourself.

[andrew-aladev]

I am using yarn npm-check-updates --upgrade that updates every package to the latest version. If upgrade process fails that I am diving into and updating each package version one-by-one to detect what package should be a focus for me right now.

If nvm upgrades it provides the following warning: nvm is already installed in /home/app/.config/nvm, trying to update using git. You have already attracted developer attension, your conscience is clear. Developer knows what he is doing.

[andrew-aladev]

The most safe way for any project life is maintenance. Maintenance means constant everyday upgrades. Developer can migrate code to the next major/minor/patch package version with ease because he won't drown in api changes.

Lets remember a project without constant maintanance from real life. We had a customer saying "I have an issue, can you please find a way to fix it?". I've opened project and found it has never been updated since 2018 year. The issue was connected with abandoned ancient version of react-select.

My resolution was the following:

1. I can upgrade react-select from version to version one-by-one simulating missing project maintenance but it will cost too much for you, because it is hard.
2. I can rewrite components that depends on react-select from scratch and it will cost less money, but still too much.
3. I can provide a fix for your issue by patching ancient and abandoned version of react-select. It is not safe and I can't provide any guarantee that patched version won't receive other issues in future. But cost is low enough.

Customer selected variant 3. Later he came and said "I had an issue with another package". I have provided another low price fix for ancient and abandoned package version. These solutions finally led to project source code death and customer finally paid new project rewrite from scratch.

Your politic with fixed version of nvm provokes same issue.

[ljharb]

None the less, the decision stands.

[rdeforest]

I understand this discussion is closed, but I'd like to summarize it to make sure I understood it and for the sake of anyone else coming here looking for answers to these questions.

• The nvm README.md explicitly references the most recent version because that is what's supported.
• The README.md does not reference an automatically updating tag because someone might automate updates and thereby break their own project when the API/UI of nvm changes in the future.
  • One impact of this is that the user's scripts will stop working violating the principle of least surprise. They might also not have the latest version of Node if they depend on their scripts to keep them updated, leading to them not getting security updates that their project needs, exposing their own users to those security flaws which are addressed in more recent versions of Node.
  • Another impact is that a project relying on nvm to update its Node might not be testing against the latest version and their own users might therefore run into problems when they update their version of Node. As long as the middle project is using the same version of nvm a difference in Node versions won't be nvm's fault.
• If someone wishes to scrape the README.md to obtain the tag of the latest supported version, compare it to their own and re-run the install as needed, it's on them if that automation breaks something.

[ljharb]

@rdeforest accurate. also, to make it clear, i do not intend to ever make breaking changes to nvm use or nvm install, so ideally bullet point 2.2 wouldn't ever happen.

[arnonuem]

@mgol Could you please open a pullrequest and put your script in a convenient file like update-nvm.sh or so? Would be nice if this would be always already shipped with the application.

[mgol]

@arnonuem It's up to the maintainer how they want to approach this. I am not sure if the Git upgrade method has some holes in it, all I know is it worked for me. I'd only recommend changing the ~/.nvm references to "$NVM_DIR" to make this more generic.

_{I also don't use nvm on my local machine anymore so I am not in a position to dive deeper here. Feel free to use my script, though.}

[nbro10]

Bump.

What's the status? Is there an easy way to self-update nvm?

[ljharb]

@nbro10 the easy way is to rerun the install script.

[nbro10]

@ljharb So, to be clear, I've once used the following command to install nvm:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash

If I use (currently, the last version)

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

What's going to happen exactly? Will this new nvm replace the old one automatically? Or will I have 2 nvms? What happens to the node versions that I installed with version nvm v0.39.5?

[ljharb]

The new one will replace the old one automatically, and all node versions will persist.

[NJT145]

as I said at #3473 , You can push your install script to releases and can make it available at anytime. And if you want to block the ones that want to automate the upgrade by blindly grabbing the latest one, you can block the update on install script, and can add a command like nvm update to upgrade nvm.