What exactly does next mean in package.json dependencies?
"dependencies": {
"react": "^15.4.2",
"react-dom": "^15.4.2",
"react-router-dom": "next"
}
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.
NPM Documentation
Specifically, and according to the documentation I found this helpful:
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.
So, for instance, I had some issues related to npm itself generating npm ERR! Error: EACCES: permission denied errors on package installations, that I first corrected by reverting to an earlier version of npm (from 5.4.0):
npm install -g npm#5.3.0
But npm is also one of those packages that does use the "next" tag in their distribution, so to take advantage of that in the newest but not officially "stable version", you could also run:
npm install -g npm#next
Which installed 5.5.1
Running: npm show npm versions --jsonshows the following version history to give an idea what exactly was installed:
[ ...
"5.3.0",
"5.4.0",
"5.4.1",
"5.4.2",
"5.5.0",
"5.5.1"
]
This answer is an attempt to state the purpose of #next more simply. The language in the docs and in other answers appears overly complex.
Using next as the version number will allow a pre-release version if the project has one available. It will otherwise allow the latest stable version.
Related
If I write "latest" as the version of a package in the package.json, every call to npm i will download the latest version of the given package.
If I write something like npm i -E somepackage#latest it will not write "latest" into package.json, but the exact version that is the actual latest version.
Is there a way to force npm to write "latest" into the package.json? We are going away from the latest tag in package.json (please no good/bad practices answers).
I am just curious wether npm supports to do this or not...
I'm building a boilerplate for my every frontend projects and if I wanted when I run npm install so all my dependencies will be the latest version, Would I change all the packages' distag to "latest" for that purpose?
"#babel/plugin-syntax-dynamic-import": "latest",
"#babel/plugin-transform-runtime": "^7.3.4",
"#babel/preset-env": "^7.3.4",
"babel-eslint": "^10.0.1"
to
"#babel/plugin-syntax-dynamic-import": "latest",
"#babel/plugin-transform-runtime": "latest",
"#babel/preset-env": "latest",
"babel-eslint": "latest"
The package-lock.json
npm v5.2+ comes with a package-lock.json file that is generated when you install packages. This file should be versioned because it contains the information of every package installed.
The idea then becomes that instead of using package.json to resolve and install modules, npm will use the package-lock.json. Because the package-lock specifies a version, location and integrity hash for every module and each of its dependencies, the install it creates will be the same, every single time. It won’t matter what device you are on, or when in the future you install, it should give you the same result every time, which is very useful.
So, if package-lock.json locks down the version of installed packages, what is the problem using "latest"?
The problem lies in that your package.json is not meaningful.
Your package.json does not tell you what version is actually installed, not even a clue.
What if someone overrides the package-lock.json or deletes it.
It is not the end of the world, but having a package.json should give us a clue about the packages we have installed.
Of course you can see a list of your installed packages with versions: npm list --depth=0 and also if you want to update packages, you can see the list of outdated ones: npm outdated
Check out this article: Everything you wanted to know about package-lock.json but were too afraid to ask.
I think it is ok when you use lastest tag as there is no conflict in version of packages.
In the user's guide of distag, they show that:
By default, the latest tag is used by npm to identify the current version of a package, and npm install <pkg> (without any #<version> or #<tag> 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.
So if you are gonna to release a stable version, use latest tag will definitely true.
I want to use latest distribution tag in my package.json for internal packages. This allows me to always get their latest versions when I npm install in local environment, without updating all external 3rd parties.
The issue comes when I'm hotfixing deployed verion:
For hotfix purpose I generate and save package-lock.json for each deployed version of the application.
But when I npm install during hotfix preparation, there is a conflict between versions of internal package in package.json and package-lock.json: package-lock.json points to version that was used in deployed application, but package.json point to latest distribution tag, which itself points to later version.
Since version specified in package-lock.json doesn't suit to version range specified in package.json (which is very specific - only the latest version will suit), npm install ignores package-lock.json and installs the latest version.
I searched through documentation and internet and didn't find any existing solution for the issue:
I didn't find any npm install flag that would treat package-lock.json versions with higher priority than distribution tag in package.json
I dind't find any tool that would reconstruct package.json from package-lock.json, or at least replace aliases (distribution tags) in package.json with specific versions from package-lock.json.
Is there any solution for my issue (besides writing a tool that will implement last approach)?
Sandbox:
https://github.com/maxlk/npm-lock-version-should-override-latest (clone and run npm install or its alternative)
I found a solution - to use npm ci instead of npm install.
It doesn't exit with error, despite the claim in the documentation: https://docs.npmjs.com/cli/ci
If dependencies in the package lock do not match those in package.json, npm ci will exit with an error, instead of updating the package lock.
If I type the following into my computer
$ echo '{}' > package.json
$ npm install pug --save
and then look at my package.json, I'll see that npm added a dependency for me.
#File: package.json
{
"dependencies": {
"pug": "^2.0.0-rc.1"
}
}
Sweet! However -- how does npm decide to grab version 2.0.0-rc.1? And how does npm decide to use the ^ SemVer version modifier?
As a user of npm can I configure or tell it to use a different SemVer modifier and/or download a different version? (both a specific version and/or something like "latest stable")
As an npm package maintainer, can I specify that npm's default behavior should be something other than "grab the latest version and slap a ^ on there"?
npm takes the latest tag publicly available and ^ is the default, you can use save-prefix to change it locally.
To a get specific version use #version after package name i.e. npm install pug#0.1.0.
Something like composer's minimum-stability doesn't exist in npm world.
As a maintainer, you can't do anything, except keeping SemVer and writeing good code :)
But at all package.json is just a JSON, you can simply modify them, without using any CLI commands and define whatever you need.
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.