https://www.creepingcoder.com/2019/10/05/using-nvm-and-nodenv-side-by-side/

NVM Settings

If nvm is already adopted on your team – great! It’s a step in the right direction, also, good amount of CI providers have support for it (e.g. Bitrise).

Add an .nvmrc file with the following content: 10.16.3 (this is current LTS version, but probably won’t be by the time you read this).

Now, you want to have a .node-version file with the same content. But although copy/paste is the best tool in a developers toolbox, it’s not the right tool for our job.

You want to symlink .node-version to .nvmrc, in order to do so, execute the following command in the root directory of your repo:

ln -s .nvmrc .node-version

Now, if you execute ls -la then you should something like that:

❯ ls -l .node-version
lrwxr-xr-x  1 steliyan  staff  6 Oct  5 19:02 .node-version -> .nvmrc

You’ve successfully symlinked .node-version to point to .nvmrc!

Conclusion

Don’t rely on the aliases that nvm supports!

Updating this file takes a minute! Testing those changes will take more time, but that’s to be expected! It may just mean to run all the integration tests locally or on your CI server. In the long term – this will save your time, and probably your ass!

The builds or environments are not reproducible. It may be OK for an evening project (but don’t forget about the psychopath who knows where you live!), but for production environment it’s absolutely not recommended! Something is going to fail when a trivial fix is being deployed. You can pray that to be the build, because more subtle errors may creep into production! However, having a broken build when you want to deploy a business-critical fix/feature is no fun.

Try answering this one question – would you produce a production build of your app without using a yarn.lock or a package.lock file? Yep, I thought so. 🙂

.NPMRC pt. 2

https://medium.com/@faith__ngetich/locking-down-a-project-to-a-specific-node-version-using-nvmrc-and-or-engines-e5fd19144245

Using .nvmrc

In your project, create a.nvmrc file to add the node version. You can use the nvm —-help to check other options. In this tutorial, we are going to use node version 8.9.0.

touch .nvmrc

Add this line 8.9.0 to the .nvmrc file.
Afterwards, run the commands below:

    nvm use
nvm install
nvm exec
nvm run
nvm which

nvm use looks for the .nvmrc and utilizes it. Remember, no trailing . spaces are allowed. A new line is required.

https://www.codejourney.net/2021/04/how-to-fix-npm-err-enoent-enoent-no-such-file-or-directory-rename/

How to fix: npm ERR! enoent ENOENT: no such file or directory, rename

I recently struggled for a while with an npm error thrown when executing npm install of some package. The error message was npm ERR! enoent ENOENT: no such file or directory, rename 'D:\\WebApp\\node_modules\\lz-string' -> 'D:\\WebApp\\node_modules.lz-string.DELETE'

Finally, I found a solution and a reason for that issue.

The error occurred when I was trying to install @testing-library/react npm package. It looked like that:

Try deleting package-lock.json

re-run npm install

Hotfix

If you ever get this error, the hotfix is to follow these steps:

• delete node-modules folder
• run command npm cache clean --force
• run command npm install
• install the package again with npm install your-package-name

It should all work fine after that. But it’s only a hotfix, a solution for now to unblock you.

https://stackoverflow.com/questions/42877722/how-can-i-add-a-npmrc-file

There are a few different points here:

1. Where is the .npmrc file created.
2. How can you download private packages

Running npm config ls -l will show you all the implicit settings for npm, including what it thinks is the right place to put the .npmrc, as this is environment/operating system dependant. But if you have never logged in (using npm login) it will be empty. Simply log in to create it.

Another thing is #2. You can actually do that by putting a .npmrc file in the NPM package's root. It will then be used by NPM when authenticating. It also supports variable interpolation from your shell so you could do stuff like this:

Get the auth token to use for fetching private packages from our private scope
; see http://blog.npmjs.org/post/118393368555/deploying-with-npm-private-modules
; and also https://docs.npmjs.com/files/npmrc
//registry.npmjs.org/:_authToken=${NPM_TOKEN}

Pointers

• http://blog.npmjs.org/post/118393368555/deploying-with-npm-private-modules
• https://docs.npmjs.com/files/npmr

In MacOS Catalina 10.15.5 the .npmrc file path can be found at

/Users/<user-name>/.npmrc

Open in it in (for first time users, create a new file) any editor and copy-paste your token. Save it.

You are ready to go.

Note: As mentioned by @oligofren, the command npm config ls -l will npm configurations. You will get the .npmrc file from config parameter userconfig

Great Install Article

https://heynode.com/tutorial/install-nodejs-locally-nvm/

Note this line Creating default alias: default -> lts/* (-> v10.16.3). This indicates that nvm has set lts/* as the default alias. Practically this means that anytime you start a new shell, and the nvm.sh script is sourced, it will default that shell to using the installed lts release. You can change this behavior using the nvm alias command.

Example to set the default version of node to use when starting a new shell to 10.0.0:

nvm alias default 10.0.0

Use nvm to install other versions of Node.js

The real benefit of nvm comes when you install different versions of Node.js. You can then switch between them depending on which project you're working on.

Should I update my npm version or use the one node.js provides?

I have a project that uses node.js 14.16.0. Both me and my teammember use that version. I use npm 6.14.11 and my teammember uses npm 7.x.x. This results in the package-lock.json being different; the lockFileVersion property is 1 on my PC but 2 on theirs.

I already use nvm and am considering to add a .nvmrc so everyone always uses the same node version, but this doesn't fix the npm version issue.

I believe that it is a good idea to use the npm version that the installed node.js version provides. If the next big LTS release uses a new npm version, the project will switch to that. But on NPM's site they say:

npm is a separate project from Node.js, and tends to update more frequently. As a result, even if you’ve just downloaded Node.js (and therefore npm), you’ll probably need to update your npm. Luckily, npm knows how to update itself!

Which makes me believe I should always update.

But they also say:

Node.js has lots of versions! To use Node.js, and therefore npm, effectively, you’ll want to make sure that you are on a version that is supported by the Node.js team. In general, you should use the version of Node.js labelled “LTS”.

Which makes me believe I shouldn't update and just use the one node.js provides.

What is the best practice? Does NPM not have a concept of LTS?

node.jsnpmversioningpackage.json

npm has a concept of LTS. In fact, they tag a release lts so you can npm install -g npm@lts and get the latest lts version, which as of this writing is 7.6.3.

npm will continue to support any major version of npm as long as it shipped with a version of node that is still supported. So they will support npm@6 until 14 goes EOL because npm@6 shipped with version 14.

That said, npm@7 is the current version of npm and it too will be supported on 14 as well for as long as 14 is supported.

If in doubt, use npm@lts (which is version 7 as of this writing). However, if you don't really care one way or the other and don't want to force your coworker to update, npm@6 will continue to receive updates as long as Node.js 14 is supported. I would recommend updating to the latest npm@6 with npm install -g npm@6 though. Either version (npm@6 or npm@7) should work just fine. You just need to pick one with your coworker to avoid the package-lock.json churn (or not care about the lockfile churn

If you have to install an older version of a package, just specify it

npm install <package>@<version>

For example: npm install express@3.0.0

You can also add the --save flag to that command to add it to your package.json dependencies, or --save --save-exact flags if you want that exact version specified in your package.json dependencies.

The install command is documented here: https://docs.npmjs.com/cli/install

If you're not sure what versions of a package are available, you can use:

npm view <package> versions

And npm view can be used for viewing other things about a package too. https://docs.npmjs.com/cli/view

https://www.w3resource.com/npm/working-with-private-packages.php

– EXCELLENT NPM RESOURCE –

Working with private packages

Last update on May 25 2020 13:26:02 (UTC/GMT +8 hours)

If you need to use private packages, your nom version must be greater than 2.7.0. and you also have to be a paid npm user.

Npm private packages, enable you to use the npm registry to host your own private code and the npm command line to manage it. This will make it easy for you to use public packages such as Browserify and Express side-by-side with your private code.

First steps (Before we start)

The first thing to do is to log in to npm again once you have upgraded to the most recent version.

npm install -g npm
npm login

Setting up your package

Every private package is scoped. If you have a package whose name begins with @, then that package is a scoped package. The scope consists of everything that is between the @ and the slash.

@scope/project-name

As an individual user, when you sign up for private modules, your scope will be your username. In the case where you created an npm Org, the orgname could be the scope. Orgs can either be free or paid. The only free way to use scopes in package names is to use public Org.

@username/project-name
@orgname/project-name

If you used npm init to initialize your packages, you use the command below to pass in your scope:

npm init --scope=<your_scope>

In the case where you are using the same scope most of the time, you probably will want to set the command above in your default configuration like this:

npm config set scope <your_scope>

Publishing your package

It is easy to publish your package; all you need to do is to run the command below:

npm publish

Scoped packages are published as private by default. Once you have published it, you should be able to see it on the website with a private flag.

Sharing access from the web

If you want to grant access to someone, they have to be subscribed to private packages as well. Immediately they are, you can then grant them read-write access. Or you could set up an npm Org that will give them access through Orgs and teams.

If you want to give someone access without using an org, you should navigate to the package page. You can find it here:https://www.npmjs.com/package/your-package-name

If you need to control access to the package, you should click the + button under collaborators.

And then add the appropriate username, and then click submit.

Sharing access from the CLI

You can equally add collaborators on the command line:

npm owner add <user> <package name>

Installing private packages

If you want to install a private package, you need to have access to the package. Then you can make use of install with the scoped package name.

npm install @scope/project-name

You can equally use the scoped package name when you are requiring it:

var project = require('@scope/project-name')

Switching from private to public

By default, all scoped packages are private. This ensures that you do not make something public by accident. This can be changed on the access page.

You can manage package access via the command line as well:

npm access restricted <package_name>

The package will be removed from listings on the site within a few minutes of making it private.

Previous: More on audit reports and requiring two-factor authentication for package publishing and settings modification
Next: Downloading packages to CI or deployment servers

Node.js

There are 2 versions of node.js – LTS and latest current version. When using npm install to install packages, are the packages installed independent of the node.js being used? Do different node.js versions install different versions of the packages?

No they don’t. When you install a npm package, it has its own version but of course package’s version and node’s version affect the usability of these packages.So, you need to delete old version of node from your system files. One more thing, please do not install npm packages global.Because when you do that, next time maybe you can use it in a other project but when it is updated by creater, you won’t be able to have new updates and features or as I said before it can’t be compatible with the new version of node.

EDIT: several years since this question was first answered, as noted in a newer answer, there is now a command for this:

nvm now has a command to update npm. It's nvm install-latest-npm or nvm install --latest-npm.

nvm install-latest-npm: Attempt to upgrade to the latest working npm on the current node version

nvm install --latest-npm: After installing, attempt to upgrade to the latest working npm on the given node version

Below are previous revisions of the correct answer to this question.

Over three years after this question was first asked, it seems like the answer is much simpler now. Just update the version that nvm installed, which lives in ~/.nvm/versions/node/[your-version]/lib/node_modules/npm.

I just installed node 4.2.2, which comes with npm 2.14.7, but I want to use npm 3. So I did:

cd ~/.nvm/versions/node/v4.2.2/lib
npm install npm

Easy!

And yes, this should work for any module, not just npm, that you want to be "global" for a specific version of node.

EDIT 1: In the newest version, npm -g is smart and installs modules into the path above instead of the system global path.

Install and Updating NVM

https://heynode.com/tutorial/install-nodejs-locally-nvm/
https://github.com/nvm-sh/nvm

A package should be installed globally when it provides an executable command that you run from the shell (CLI), and it's reused across projects.

You can also install executable commands locally and run them using npx, but some packages are just better installed globally.

Great examples of popular global packages which you might know are

• npm
• create-react-app
• vue-cli
• grunt-cli
• mocha
• react-native-cli
• gatsby-cli
• forever
• nodemon

You probably have some packages installed globally already on your system. You can see them by running

npm list -g --depth 0

on your command line.

Global NPM

https://nodejs.dev/learn/npm-global-or-local-packages

npm global or local packages

The main difference between local and global packages is this:

• local packages are installed in the directory where you run npm install <package-name>, and they are put in the node_modules folder under this directory
• global packages are all put in a single place in your system (exactly where depends on your setup), regardless of where you run npm install -g <package-name>

In your code you can only require local packages:

JScopy
require('package-name')

so when should you install in one way or another?

In general, all packages should be installed locally.

This makes sure you can have dozens of applications in your computer, all running a different version of each package if needed.

Updating a global package would make all your projects use the new release, and as you can imagine this might cause nightmares in terms of maintenance, as some packages might break compatibility with further dependencies, and so on.

All projects have their own local version of a package, even if this might appear like a waste of resources, it's minimal compared to the possible negative consequences.

https://josipmisko.com/posts/how-to-update-npm-packages-in-4-easy-steps

Have you ever tried to update a npm package and then realized that it breaks all other packages in your Javascript project?

This is a common problem for web developers, luckily there are some easy steps to take before updating a module.

In this blog post, I will show you how to update npm packages without breaking your project by following 4 simple steps:

1. Understand npm package versioning
2. Audit installed npm packages
3. Update only one npm package at time
4. Test your code after updating npm packages

Cheat Sheet: 6 must-know commands to update npm packages

Step 1: Understand npm package versioning

Versioning is an important part of npm and how to use updates safely when developing web applications.

Most npm packages follow semantic versioning guidelines.

Semantic versioning means that developers should compose a package version of three numbers separated by periods (e.g., "0.12.31").

MAJOR.MINOR.PATCH versioning format

The first number, called the major version, indicates how significant a release this is in relation to other releases with the same minor and patch levels. Major version number indicates incompatible API changes.

The second number, called the minor version, indicates how much new functionality has been introduced since the last significant release; for instance, if this change was only small fixes or enhancements to existing features and no behavior changes were made then it would result in a higher value. Minor releases are not as risky as major version because they typically introduce new features, but they are not as risky as major updates because no API changes were made.

The third number is called the patch version and it indicates how much bug fixes or enhancements have been introduced since the last minor release; for instance, if this change was only small fixes or enhancements to existing features and no behavior changes were added.

What do the caret (^) and tilde (~) mean?

In package.json, a version can have a ^ in front (e.g. ^0.12.31), meaning the latest minor release may be safely installed.

Tilde (~) in front (e.g., ~0.12.31) means the latest patch release is safe to install.

An example of npm packages that are listed as dependencies in the package.json file. All dependencies have a caret (^) in front, showing that it is safe to install the latest minor versions.

package.json
package.json is a file that keeps track of all the packages your app needs to run properly, as well as settings for how it should behave when running on different platforms and environments.

Step 2: Audit installed npm packages

Before you update npm packages, figure out if you have a good reason to.

It is better to stick with the package version that works. That way you will not have a risk of something breaking.

Primary reasons for upgrading npm packages are:

• Recent version of the package having a feature that we want
• Fixed bugs in the latest version of an npm package
• Updated dependencies for another package that you are using
• A security vulnerability in the npm package
• Upgrade of the environment where the project is running is not compatible with the the current version of the npm package

Couple of npm commands that will help you audit your packages before upgrading:

• npm list --depth 0 lists all packages at the top level
• npm audit checks for security vulnerabilities or out-of-date versions
• npm outdated lists report of package versions compared to versions specified in package.json file

npm list –depth 0

npm list --depth 0 lists all installed npm packages, but only at the top level.

Listing packages at the top level is enough most of the time. Top-level dependencies usually take care of their inner dependencies.

npm audit

npm audit will run a security vulnerability check against your project and report any found issues. It is not perfect, but it helps to find potential problems if you are using npm packages that have security vulnerabilities. It's not perfect because not all vulnerabilities are reported to npm.

npm audit shows you a list of vulnerable packages, including the npm dependency tree.

npm outdated

npm outdated will report any out-of-date packages in your project.

It shows current, wanted and latest versions compared to versions specified in package.json file.

• Current: is the currently installed version.
• Wanted: The maximum version of the package that is allowed by the version range in package.json.
• Latest: version of the package is the one that is tagged as "latest" in the npm registry.

Note: npm outdated command only shows the direct dependencies of the root project. But if you want to see other dependencies also, then use "–all."

npm outdated prints out a list of all installed packages that have updates available.

Check for breaking changes before you update

Some npm packages will introduce breaking changes, which may cause errors when using the module.

Before making a breaking change, package developers often add "Breaking Changes" messages to the console output. It means that the module will change in future versions and developers need to keep an eye out for it.

To see if there are any breaking changes, you can also look at the "Breaking Changes" section of the package's readme file.

You can usually find package's readme file in:

• npm package's page on the npm registry
• inside of a module directory, check node_modules folder inside of your project
• project's website (or GitHub)

Step 3: Update only one package at time

When updating, we need to be careful to only update packages we want. There is no need to update all of your modules at the same time.

Start by making updates in small batches and test each batch for any issues that might arise. This will allow you to find out how it's affecting your project, and it will let you isolate any errors.

npm update

Changing the package version in package.json file and running npm install will most likely not do anything because already installed package version satisfies the versioning in the package.json file.

Rather than using npm install, you can use the npm update command to upgrade already installed packages. When you run a npm update, npm checks if there are newer versions out there that satisfy specified semantic versioning ranges that you specified in package.json and installs them.

To update a specific npm package, run the following in console:

npm update package_name

How to revert npm package updates?

If there are any bugs, you can easily undo the changes with these two commands:

npm uninstall package_name
npm install package_name@version

The @version should be the same version that you had installed previously.

Step 4: Test your code after installing new packages

In order to make sure your code still works after updating npm packages, it's important that you test the functionality before deploying. This is because a package update may cause errors in your application if you are not careful. To avoid these issues, I recommend running all tests on server and client side as well as manually checking for any JavaScript error messages throughout the site.

Steps:

• Run all unit and integration tests from both serverside and clientside by running npm test or equivalent command for your project.
• Review package logs for clues about what caused an issue or where things went wrong during installation

These 3 simple steps can help you avoid breaking your project by carefully installing new npm packages.

What are some of the other ways that people have broken their projects? Let us know in the comments below, and we'll write a blog post on them!

Bonus Tip: Clear npm cache

As of npm@5, the npm cache self-heals from corruption issues and data extracted from the cache is guaranteed to be valid. If you want to make sure everything is consistent, use 'npm cache verify' instead. On the other hand, if you're debugging an issue with the installer, you can use npm install --cache /tmp/empty-cache to use a temporary cache instead of nuking the actual one.

Sometimes npm doesn't pull the latest version of the package because it has an older version stored in cache. As of npm@5, cache issues should not be happening. But they still do sometimes.

To clear npm cache, run npm cache clean --force. This command clears npm's cache of all the packages that your project has installed with npm install or npm update.

It does not remove any dependencies from package.json, but it may help resolve a dependency issue if there is an outdated version in the cache and you can't find which one it is by looking through the packages list.

Cheat Sheet: 6 Commands To Help You Update npm Packages

This cheat sheet will make it easy to safely update npm packages in your node application. It includes a list of commands that will help you keep up with the latest updates and avoid breaking changes.

• Use npm list --depth 0 to list all the packages in your package directory
• Use npm audit to find out which of your npm dependencies are vulnerable.
• Use npm outdated to list the packages that are out of date with respect to what is installed in package.json
• Use npm update package_name to update an individual package that has already been installed.
• Use npm uninstall package_name and npm install package_name@version to revert to a specific version.
• Use npm cache clean --force to clear npm's cache of all the packages that have been installed.