How can I avoid installing unstable releases of mongoose with npm?
After running npm update, I get the following warning in my node app:
# !!! MONGOOSE WARNING !!!
#
# This is an UNSTABLE release of Mongoose.
# Unstable releases are available for preview/testing only.
# DO NOT run this in production.
In my package.json file I have the following entry:
"mongoose": "^3.8.8"
Mongoose is not following standard npm practices and so their unstable builds get recognized as stable by npm. Basically they released 3.9 as an unstable version, this is what causes the warning.
My advise is that you don't trust them anymore to follow such conventions and just lock the version in your package.json:
"mongoose": "3.8"
Check out this answer: How do I update each dependency in package.json to the latest version?
The advice is that if you specify "*" as the version then you will always be updating to the latest stable version.
In your case, I'd recommend uninstalling the mongoose package first and then reinstalling mongoose.
The code:
npm uninstall mongoose
(change "mongoose":"^3.8.8" to "mongoose":"3.8")
npm install
You probably never installed 3.8.8 in the first place (which should be stable) but a 3.9.x version.
Actually, with the ^ you will also install 3.9.x when having ^3.8.8 in the package.json.
In your case, you can either fix the 3.8.8 (or 3.8.18 which is stable as of today, as described in other answer here, by removing the ^) or use th ~ character, which will only match new version on the lowermost version part.
So the following will match (with x being latest available):
* => x.x
^3.8.8 => 3.x
~3.8.8 => 3.8.x
3.8.8 => 3.8.8
Since 3.9 is considered unstable, but ^ will go to 3.9, that is the problem.
Good explanation on version is also found here: https://stackoverflow.com/a/22345808/586754
and use
npm view mongoose versions
to see what versions are available, e. g. what is latest in 3.8 on when 4 is out.
With ~3.8 it will always stay latest in 3.8 (on update), but you will need to update it manually once 4.0 is out.
Also: you can edit the package.json directly and then run
npm update
without having to uninstall/reinstall.
Related
If you connect a github project to a product like cloudflare pages or Vercel, commits to the remote repo trigger new builds. These builds will run the appropriate install and build commands. I haven't updated a site in months, but major changes have come to dependencies being used and it's causing me so many headaches to try and go through one-by-one and address each and every issue that has surfaced. I'm using pnpm, is there anyway I can have pnpm install look at the existing pnpm-lock.yaml so I can eventually build a project that is entirely the same as a previous build I had 6 months ago? I just want to edit some text on my site and not have to make all these updates. I tried "freezing" the versions of all my dependencies and dev dependencies in package.json by removing instances of ^ to match what I see in my lock file, but that didn't work.
Package Management with PNPM
See also why-does-npm-install-rewrite-package-lock-json
Semver
The semver specification explains how to use semantic versioning though you can probably skip to the npm docs.
As you probably know the numbers are in the form major.minor.patch. If you don't mind which patch release you have as long as it is the specified major and minor version you can use the ~ prefix. Similarly, to allow any minor version use ^.
Walkthrough
Inital Setup
pnpm init
pnpm add express
The package.json will contain (at time of writing):
"express": `"^4.18.2"`
A pnpm-lock.yaml is also created:
specifiers:
express: ^4.18.2
dependencies:
express: 4.18.2
express -> '.pnpm/express#4.18.2/node_modules/express'/
Using pnpm install
Giving it a first run without changing anything produces:
$ pnpm install
Lockfile is up to date, resolution step is skipped
Already up to date
Done in 653ms
Now if I change package.json to be exactly v4.16.0 we shall see an update to pnpm-lock.yaml
specifiers:
express: 4.16.0
dependencies:
express: 4.16.0
Adding the patch wildcard ~4.16.0 and running pnpm install again gives:
specifiers:
express: ~4.16.0
dependencies:
express: 4.16.0
Note that the install version did not change. If I delete the node_modules/ directory and reinstall, still no change.
Ok, now try updating the minor version in package.json to ~4.17.0.
specifiers:
express: ~4.17.0
dependencies:
express: 4.17.3
This time it did update the dependency and installed the latest patch version but did install the exact major and minor version. If you think about what the ~ means then this is expected.
The specifiers section in the lock file is just what we specify as the dependency in the package.json file. The dependencies section in the lock file should reflect the version that is installed, or will be installed.
If I delete the node_modules/ folder and pnpm install again then we still have 4.17.3.
Explanation
What confuses a lot of people about pnpm install/npm install is how the lock-file works with the semver specifier:
The installed version listed as a dependency in the lockfile must be compatible with the version specified in the package file.
If it is compatible, no changes will be made.
If it is incompatible, then the latest compatible version will be installed.
Perhaps because sometimes it seems to install the latest version, and not othertimes, the behaviour is not clear. To state this again, changes will only be made when there is an incompatibility between the packge version and lockfile version. The lockfile dependency never has the ~ or ^ wildcards because only one version is actually installed and that's what the lockfile is supposed to track.
Using --frozen-lockfile in a CI environment
The docs for pnpm install describe how the install will fail if the lockfile is out of sync or needs updating.
Changing the package.json back to ~4.16.0 and then doing the install:
$ pnpm install --frozen-lockfile
Lockfile is up to date, resolution step is skipped
ERR_PNPM_OUTDATED_LOCKFILE Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with package.json
Note that in CI environments this setting is true by default. If you still need to run install in such cases, use "pnpm install --no-frozen-lockfile"
In fact, even if I specify the installed version exactly 4.17.3, because it differs to the specifier ~4.17.0, then it will err. The package.json and pnpm-lock.yaml are out of sync even though the version are compatible.
Finally I will make our package compatible with the latest version that was installed with the first pnpm add express command. To do this I use the minor version wildcard ^4.0.0 and unfreeze the lockfile with pnpm install --no-frozen-lockfile.
specifiers:
express: ^4.0.0
dependencies:
express: 4.17.3
While the specifier is updated to match the package file, the version is not chaged; it is compatible.
Running pnpm install --frozen-lockfile will work again, but not update the installed version.
Conclusion
In a normal environment the lockfile will determine the exact version installed unless it is not compatible with the package file, in which case it will install the lastest version specified by the package file.
In a CI environment the lockfile will not by default be updated and will need to be compatible with the package file for installs to occur.
If you want the latest version specified pnpm update will do the update to the lastest compatible version given in the package file.
Disclaimer
I've tested out everything here but it is complex and I have limited experience using pnpm in a real CI environment.
before deploying your project delete pnpm-lock.yaml
I have a React app. (though for the purposes of this question, the tech doesn't matter)
One of the dependencies is the material-ui library.
A dependency of the material-ui library is the react-transition-group library.
Does this then mean that I can "npm install" the react-transition-group library without increasing the size of my JS bundle at all?
It will depend on the versions of react-transition-group that are used. npm will do it's best to install only a single version of a module. Modern bundlers (Webpack/Rollup) will also try to use a single version inside the bundle.
So when will it use a single instance and when will you get 2 copies?
Version Ranges overlap:
material-ui requires version ~1.1.0
Your package.json requires version ^1.0.0
Since those ranges overlap, npm can install any version that matches 1.1.* and it will work for both modules, and you'll get only 1 copy.
Version Ranges don't overlap:
material-ui requires version ~1.1.0
Your package.json requires version ^2.0.0
Since those ranges require different SemVer major versions, npm will install two copies, one to fulfill each requirement. The bundler will also need to bring in both versions.
It can be hard to tell exactly what version exists in a sub-dependency, but you can see them all by running npm ls after running npm install it will show you all packages and version that are installed in the project.
I am working on a project which has gulp as a dependency. I am looking at updating it to gulp 4. A quick look at the output of npm show gulp#latest shows
...
dist-tags:
latest: 3.9.1 next: 4.0.0
...
I wonder why the gulp team have left latest: 3.9.1 and choose next: 4.0.0, i.e. npm install gulp installs 3.9.1 while to get 4.0.0 one has to ask for npm install gulp#next. Why is the default version still 3.9.1? Is version 4.0.0 still not fully supported or something? I have not found anything regarding this on the gulp website.
From the npm dist-tag docs:
By default, the latest tag is used by npm to identify the current
version of a package, and npm install (without any # or
# specifier) installs the latest tag. Typically, projects only
use the latest tag for stable release versions, and use other tags for
unstable versions such as prereleases.
The next tag is used by some projects to identify the upcoming
version.
By default, other than latest, no tag has any special significance to
npm itself.
In this case latest is 3.x.x and next is 4.x.x As it is following semver, it means that there are backwards incompatible changes. If you check gulpjs.com, the link to the documentation brings you to the 3.x.x docs. It's the authorative version at the moment as set by the gulp maintainers.
I just want some confirmation as I've always been using #latest for a while with my packages and want to know if I'm really installing a stable version or can possibly install a alpha/beta version of the package.
I'm pretty sure this is meant for stable versions as they tell you to install#latest for npm (unless it's special syntax like npm start).
The more I think about it, the more paranoid I get, any confirmation would be greatly appreciated. :)
Using npm install <pkg>#latest is equivalent to using npm install <pkg> by itself or listing * as the dependency version in package.json. npm documents this here:
npm install will use the latest tag by default.
So in practical terms, latest is semantically equivalent to stable.
However, if a prerelease version of a package is published to npm without specifying a prerelease tag such as --beta or --rc, that version becomes the latest by default:
By default, npm publish will tag your package with the latest tag.
As a result, it's possible to mess up and publish a prerelease version that will be installed by default. This happened to Bootstrap in late 2015.
This article from early 2016 by Mike Bostock explains how even specifying alpha or beta as part of the version number won't prevent npm from making that version the latest.
So unfortunately if you want to be certain that you get only stable versions, you need to monitor this manually or trust the package developers to always specify a prerelease tag for non-stable versions.
You can also view the tags assigned for a package like this:
$ npm view express dist-tags
{ latest: '4.16.2', rc: '4.0.0-rc4' }
I have an npm package with a fixed version that has an update.
Example package.json extract:
devDependencies: {
"someFixedVersionPackage": "1.0.0", //1.1.0 is latest
"anotherFixedVersionPackage": "2.3.2", //2.3.4 is latest
}
Does an npm command exist which installs the latest version of that package and updates the package.json, preferably all packages at once?
To be clear, I want the package.json snippet above to be updated to this, in addition to the packages themselves being updated:
devDependencies: {
"someFixedVersionPackage": "1.1.0", //latest
"anotherFixedVersionPackage": "2.3.4", //latest
}
Thank you.
Why doesn't npm update work here?
As per the documentation on npm update:
This command will update all the packages listed to the latest version (specified by the tag config), respecting semver.
It will also install missing packages. As with all commands that install packages, the --dev flag will cause devDependencies to be processed as well.
Since your packages are defined with a fixed version, the update sub-command will not update those to respect semantic versioning. Therefore, it will only automatically update your packages if you specify a greater version range for each package. Note that it is actually typical in an npm project to specify a loose range version; one that is meant to avoid breaking changes but still leaves room for improvements and fixes.
Still, why shouldn't I fix dependency versions in my package.json?
But they are fixed because I wanted them so. After testing newer versions, I want to update them via command line as were created.
Having a list of dependencies with a fixed version does not mean that the dependencies installed will always be the same, because the dependencies of your dependencies will most likely also be defined with a version range. In order to keep track of a list of tested version-tagged dependencies, npm provides another mechanism: package locks.
Before version 5 of npm, you can create a "npm-shrinkwrap.json" file with the shrinkwrap command:
npm shrinkwrap
This command locks down the versions of a package's dependencies so that you can control exactly which versions of each dependency will be used when your package is installed.
Since npm 5, a "package-lock.json" is automatically generated when an npm operation modifies the "node_modules" tree or "package.json".
Rather than modifying package.json, either one of these package locks will override the default behaviour of npm install, installing dependencies with the versions specified by the lock, right when they were created or manually updated. With that out of the way, your dependencies can now be expanded without the risk of dependents installing untested package versions.
Shrinkwraps are used for publishing packages. To shrinkwrap a package:
Run npm install in the package root to install the current versions of all dependencies.
Validate that the package works as expected with these versions.
Run npm shrinkwrap, add npm-shrinkwrap.json to git, and publish your package.
At this point, dependency versions can be loosened in your package.json (this will hopefully be done only once every major dependency update), so that later on they can be updated at will with npm update:
"devDependencies": {
"someFixedVersionPackage": "^1.0.0",
"anotherFixedVersionPackage": "^2.3.2",
}
The package-lock.json file can be used instead of a shrinkwrap, and is more suitable for reproducing a development environment. It should also be committed to the repository.
So how do I update my dependencies?
Calling npm update will do what's mentioned above: update dependencies while respecting semantic versioning. To add or upgrade a dependency in a package:
Run npm install in the package root to install the current versions of all dependencies.
Add or update dependencies. npm install --save each new or updated package individually to update the package.json, as well as the existing package locks ("package-lock.json" and "npm-shrinkwrap.json"). Note that they must be explicitly named in order to be installed: running npm install with no arguments will merely reproduce the locked dependencies.
Validate that the package works as expected with the new dependencies.
Commit the new package locks.
Moreover, here are a few tips for a smooth transition from a project with fixed dependencies:
If you haven't done so, expand the version range by adding a tilde (~) before the version specifier, or a caret (^). npm update will then attempt to install all patch revisions and minor revisions, respectively (major version 0 is a corner-case, see the documentation). For instance, "^1.0.0" can now be updated to "^1.1.0", and "~2.3.2" can be updated to "~2.3.4". Adding the --save or --save-dev flags will also update the "package.json" with the installed version (while keeping the previous range specifiers).
Run npm outdated to check which packages are outdated. Entries in red will be updated automatically with npm update. Other entries will require a manual intervention.
For packages with major version bumps, install that package with a version specification (e.g. npm install browserify#11.2.0 --save-dev). Further issues that may arise with the update will have to be handled manually. It usually helps to read the news feed or the release history on that package to further understand what has changed from previous versions.
This is not simple enough, is there another way to do this?
Before continuing, it is always worth mentioning that packages have a SemVer-compliant version definition for a reason. One should avoid blindly installing the latest version of every single package. Although such a full update can be done and tools are available for that, some caution is advised. For instance, you would not want to install React 15 if the remaining React components and libraries are not compatible with react#15.x.x. See also npm's blog post: Why use SemVer?
I'll take my chances. What other tools are there?
To name a few:
npm-check-updates will do what was initially asked in the question: install and update the versions of all dependencies, regardless of the given range constraint. This would be the least recommended tool for the job, however.
updtr will update dependencies one by one and roll back to the previous version if the project's tests fail, which may save time in projects with good test coverage.
npm-check provides an interactive command-line interface, which allows you to easily select which packages to update.
Is this any different with npm 5?
Since major version 5, npm will automatically create a "package-lock.json", which will fill the role of specifying the dependency tree when a shrinkwrap does not exist. A more detailed description can be found in the package-locks documentation. In general, npm-shrinkwrap.json is meant to be used when publishing, whereas package-lock.json is to be used in development. This is why you should also commit "package-lock.json" to the repository.
What about with Yarn?
Yarn, an npm-compatible dependency manager, creates a lock file automatically on use, which behaves similarly to the npm shrinkwrap. Calling yarn upgrade «package» will update one dependency to the version in the latest tag, regardless of the version range recorded in the package.json or the lock file. Using yarn upgrade-interactive also allows you to selectively upgrade packages to the latest version, not unlike npm-check.
$ yarn outdated
yarn outdated v0.16.1
Package Current Wanted Latest
babel-eslint 7.0.0 7.0.0 7.1.0
chai 3.0.0 3.0.0 3.5.0
Done in 0.84s.
$ yarn upgrade babel-eslint chai
yarn upgrade v0.16.1
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 2 new dependencies.
├─ babel-eslint#7.1.0
└─ chai#3.5.0
Running the following command will do what you want:
npm install someFixedVersionPackage#latest anotherFixedVersionPackage#latest --save-dev --save-exact
Breakdown:
npm install someFixedVersionPackage#latest will install the latest version of the package
The --save-dev flag will cause it to update the version in your package.json's devDependencies
The --save-exact flag will cause it to save a fixed version instead of a semver range operator
Link to the npm install docs
I've been looking for an easy way to update npm dependencies for a long time. Then I found this tool: https://github.com/dylang/npm-check
It shows you which dependencies are out of date in a nice ui and allows you to update them. It even tells you which ones are likely to break due to major changes and warns you of unused dependencies.