Make it possible to persist the default-packages in my dotfiles

[DeusProx]

Like the title says. I have a .dotfiles repo and I would like to be able to persist the file which saves the list of npm packages which should be installed when installing another node version. This file is saved as $NVM_DIR/default-packages, which is usually .nvm/default-packages. This though is currently not possible, since the .nvm directory itself is a git repository.

For Linux it would be great for example to save this as .config/nvm/default-packages. To make it more configurable one could create a separate environment variable for the nvm confiuguration with the name NVM_CFG or NVM_CONF and set it default to .config/nvm and also search the default-packages file as $NVM_CFG/default-packages respectively $NVM_CONF/default-packages.

[ljharb]

You can symlink the default-packages file anywhere you want; that’s how i get things into my Dropbox.

[DeusProx]

Sure, but then I need to create the symlink when installing my dotfiles on a new system, because I also cannot persist the symlink since it is inside the .nvm directory. I understand that this is a low priority issue/first world problem, but I still would prefer nvm to "natively support" an external configuration file in a similiar way like all my other terminal tools. Hence the feature request.

Just generally would the nvm project accept this as a feature? It's probably just a new environment variable and a change to this function to check for all possible paths to the default-packages file, I assume?

Question left is how to handle if there is more than one default-packages file due to the new possible location. I think it would be best to do it in a backwards compatible way so $NVM_DIR/default-packages should be loaded with higher priority than .config/nvm/default-packages which only applies to packages where a version is applied in one of the files, but in most cases one could probably just load both files.

[ljharb]

Surely you already have to do that for your shell profile files, which have mandated locations?

To be clear I'm very uninterested in further XDG compliance; nvm already meets all the MUSTs, and I don't find value in the rest.

If this were to be implemented, it would be via an env var, and the env var would take precedence over the original file. If the new file were not present but the original one were, it would probably warn, and read the original one instead.

I remain hesitant to add to the complexity of the project for something like this, especially since even having globally installed packages is commonly considered an antipattern (that's what npx is for)

[DeusProx]

Surely you already have to do that for your shell profile files, which have mandated locations?

You mean like having ~/.bash_profile and ~/.profile as symlinks into my dotfiles? My repo is just directly my ~/ directory so I could easily add them without any symlinks. I just have ~/.git pointing gitdir to my dotfiles repo. Sure, I will probably still have other scripts for installing and setting stuff up, but my target was trying to keep the number low.

I remain hesitant to add to the complexity of the project for something like this, especially since even having globally installed packages is commonly considered an antipattern (that's what npx is for)

Didn't knew yet that globally installed packages are considered an anti-pattern and one should use npx instead. That's good to know. Sadly one of my use-cases is that I use some packages like typescript-language-server to have proper lsp support in neovim. Since nvm owns the central processes of installing and updating new node versions using the default-packages is practically the only solution without any extra moving parts.

In the end it is the decision of the maintainers though as one symlink is definitely a solution a user needs to accept.

[ljharb]

If it's already ~ then you wouldn't need a symlink because ~/.nvm and ~/.nvm/default-packages would already be in your repo, no?

[DeusProx]

Not really since ~/.nvm is already checked out as this git repo here itself and thus I can't add files in that directory. Removing ~/.nvm/.git would probably also enable me do this, but this would again be another manuell thing or script todo. I also think it's good that it stays a git-repo if one ever needs to fetch/checkout or wants to to collaborate. Forking and keeping the file there also is a solution, but then I would have my configuration in this fork repo and not in my dotfiles.

[ljharb]

ohh i see what you mean. could you add ~/.nvm as a submodule of your root repo?

[brianarn]

I ran across this issue while looking for a similar such feature. I'm using Neovim, and its Node.js Provider option would like to have the neovim package installed globally.

I'm also in a situation where the computer I'm running on is managed corporately, and nvm is automatically installed, and I've found that I can't reliably keep .nvm in my dotfiles, as it may get stomped on by a reinstall process.

The idea of an environment variable, like NVM_DEFAULT_PACKAGES_FILE, seems like it could be really useful. If contributions are accepted, I'd happily take a shot at it myself.

[ljharb]

@brianarn what reinstall process would overwrite ~/.nvm? Anything doing that will likely delete your installed node versions, which means it's terribly broken.

[brianarn]

Oh it absolutely gets rid of installed node versions if that happens, but I've seen it happen before. Not all the time or often, but I've lost my Node installs before. It's not good, but it's been infrequent enough that I've not been able to figure out if it's intentionally removing nvm or trying to "upgrade" nvm or what's going on.

I do also use some ephemeral environments where it's basically a new machine each time with a new .nvm getting installed as part of system setup.

Worst case, I can work around not having this feature by basically creating a simple alias that does an install of packages for me that I keep in my dotfiles and run from there, but figured I'd put a simple +1 on this sort of feature request. :)

[ljharb]

homebrew certainly does that, which is the primary reason it's not supported for installing nvm. Please let me know if you see anything else doing that.

Appreciate the +1. In the meantime, something that copies the default-packages into $NVM_DIR seems like an easy workaround.

[ljharb]

This seems answered, but will be happy to reopen if needed.