react-dev-utils#11.0.4 installing a vulnerable version of browserlist, browserslist#4.14.2, although we have updated package on github. https://github.com/facebook/create-react-app/blob/main/packages/react-dev-utils/package.json#L57
[to test out, you may simple create any folder and do npm i react-dev-utils and then check it using npm ls browserlist]
I dont get, what all are the constraint for this. (I dont see any package-lock.json for this package, which could be a potential reason for the vuln). older version has reported vulnerability CVE-2021-23364.
react-dev-utils#11.0.4 installing a vulnerable version of browserlist, browserslist#4.14.2, although we have updated package on github
This is because that package.json file resides in the default branch which usually contains the latest or development code. At the time you posted the question, that change was not published to the npm registry.
react-dev-utils#11.0.4 has browserslist#4.14.2 listed in its package so that's the version that will be installed. Reference: https://cdn.jsdelivr.net/npm/react-dev-utils#11.0.4/package.json
You need atleast react-dev-utils#12.0.0 to fix that vulnerability. See the versions tab.
[to test out, you may simple create any folder and do npm i react-dev-utils and then check it using npm ls browserlist]
Running that command will install the latest version of react-dev-utils, which now has no vulnerability. So it will fix your issue.
I dont see any package-lock.json for this package, which could be a potential reason for the vuln
package-lock.json cannot be published to registry, only the top level lock file is respected. Reference: Should package-lock.json also be published?
this may be an example package, but how in general we update to latest package? have tried npm update as well.
npm update respects the semver range that you've set in your package.json. If its like "react-dev-utils": "11.0.4" that command won't do anything. If its "react-dev-utils": "^11.0.4", it will try to update to the latest 11.x.x version which you are already on, so again it won't do anything. Reference: npm update does not do anything
In general if you want to upgrade every direct dependency to latest version you can use npm-check-updates before running npm update. Refer https://nodejs.dev/learn/update-all-the-nodejs-dependencies-to-their-latest-version for detailed guide. Related: How to update each dependency in package.json to the latest version?
Now, if it is not a direct dependency, as was in your case, you can force resolutions. This is natively supported in Yarn and NPM v8.3.0 and above. In older NPM versions you need to use a dependency like npm-force-resolutions. Related thread: npm equivalent of yarn resolutions?
There are much more related threads that you can easily find by searching on the web.
Related
I'm new to NPM. I'm getting an alert from github dependabot saying my json-schema package is vulnerable. My current json-schema version is 0.2.3, it's required by my current npm#7.20.6 via transitive dependency on jsprim#1.4.1. I can't update my npm version right now since that involves lots of testing which I don't have time to do right now. Wondering what's a good way to force npm to use a newer version of json-schema. (0.4.0 is the version I should use.) I was thinking updating package-lock.json to use json-schema#0.2.3, but if I run npm install, that change will be erased right? Some examples would be appreciated!
I am learning about the differences between package.json and package-lock.json
I been experimenting on a package with only one dependency called chance
I first installed it via npm i chance#1.0.0 and the package.json has "chance": "^1.0.0" and package-lock.json has "version": "1.0.0".
Because I wanted to see the effect that the lock file has on the version, I went ahead and deleted package-lock.json and node_modules, I ran npm install, the version of chance stays the same in package.json, which is "chance": "^1.0.0". In the newly created lock file, the version of chance became "chance": {"version": "1.1.8",, so it updated itself.
I then deleted package-lock.json and node_modules again and ran npm update, the results seemed to be the same with the previous experiment – in package.json I have "^1.0.0" in package.json and "1.1.8" in package-lock.json
My questions are:
in either case, with "^1.0.0" in package.json and "1.1.8" in package-lock.json, which version of the dependency am I actually using in my project, I guess it is 1.1.8 right? so by merely looking at the versions in package.json is not enough to determine the exact version of the dependencies used in a project?
When does running npm install change the lock file? I know that if we delete the lock file, it will generate a new one with the newest versions in the allowable ranges from package.json. But are there any cases where npm install would change the lock file even if I didn't delete the lock file?
So, the answer is a bit complex. Essentially there are 2 things at play: The version of the package you want/need, and the version of the package that is installed.
When you are building a project, you probably don't care what specific version of a given dependency is. Most of the time you want the latest one, or the latest patch near a specific major version. The package.json is supposed to document what you, the developer, believe is required for your project to work. So, if you put in the package json "chance": "1.0.0", it would mean that only version 1.0.0 exactly is acceptable, and any other version is unacceptable. If you put "chance": "^1.0.0", it means any version compatible with 1.0.0 is acceptable. So 1.2 or 1.3 might also be fine, but 1.4 might introduce a change that breaks compatibility.
Once you decide what packages you want, by writing the package json, you run npm install. npm install can't always install exactly the versions you want. For example, imagine you want to install two packages: React v1.13 and momentJS v2.8. So you add these to your package json like this:
(Note: these version numbers and dependancies are not based on real React or Moment version numbers)
"momentJS" : "2.8",
"react" : "1.13"
then you run npm install. And you get an error: Package dependencies cannot be resolved. (or something like that). The problem is that React version 1.13 requires momentJS 2.9, but your package json specifies that you want version 2.8 exactly. You can't have both, so npm isn't able to resolve the conflict. A fix would be:
"momentJS" : "^2.8",
"react" : "1.13"
Now you are saying that you need a version of moment compatible with 2.8, and you are okay with npm adjusting that to satisfy other packages. Run npm install again and npm might install version 2.9, which satisfies both your requirement of "compatible with 1.8" and React, which wants 2.9. Now, the web app I'm currently working on has over 1,000 dependancies total, so npm absolutely needs to be able to adjust version numbers in order to get all of those packages to play nice.
Now there is often more than one way to solve a dependancy graph--more than one way to adjust all the version numbers to make every package happy. Your package lock file records what the current solution is and what actual packages are installed.
All the options for specifying package verions are here
Hope that helps!
Also: the second part of your question was "will npm change the lock file without me deleting it?" And the answer is: basically everytime you run npm install, npm changes the lock file. What npm does try to do is change the lock file as little as possible with each new install and keep most packages the same
Say you get a warning in some libraries in a repo about security concerns from github. You want to quickly bump the version just to make the github warnings going away. You are not worried about re-installing, rebuilding and testing.
Is there a way to do this with npm?
npm update mypackage does not do anything.
Now it works different, if you notice package versions in package lock.json have a prefix, sometimes its ~ sometimes ^, they have big importance when it comes to package updating, as fixing package mismatches is the worst hell.
Suppose you have package in package.json called packX with version ~1.1.1 or ^1.1.1
When you run npm update for packX npm will first of all check the version prefix for it.
If there is ~ in this case it will be understood as install packX version >=1.1.1 and <1.2.0 so the highest version it can install can only be in range of 1.1.N, it will not go up to 1.2.N.
If there is ^ then it will be understood as >=1.1.1 <2.0.0 so the highest version that can be installed will be in range of 1.N.N but connot go up to 2.N.N
Hope My explication is clear enough, anyways you can check the docs for details
npm update will only update minor versions.
Eg: It will update version 1.2.3 to 1.5.2
But it will not update version 1.2.3 to 2.0.1 because there can be breaking changes.
To check new major releases of the packages, you run npm outdated
To update to a new major versions for all the packages, you can use npm-check-updates
npm install -g npm-check-updates
Then run ncu -u
This will upgrade all the versions in the package.json file, to dependencies and devDependencies, so npm can install the new major version. Now you can update packages to new major releases by npm update
Reference
Inside a Node.js project, it's not clear to me what is the correct workflow to ugpgrade a package to a major release.
Let's suppose I'm istalling stylelint: npm install --save stylelint by default puts inside my package.json the string "stylelint": "^8.4.1" which means that if I want to update it with npm update, I will get only minor and patch releases (8.4.2 is ok, 8.5.0 in ok, 9.0.0 is not).
If I check with npm outdated and it comes out that I could update to 9.0.0, npm update wouldn't work because of the restriction depicted above.
So, if I want to upgrade, what am I supposed to do?
Have I to manually modify my package.json to stylelint version ^9.0.0, delete node_modules directory and re-run npm install?
Or maybe I have just to remove the ^ character to let npm update do its job?
What is the common/best practice to adopt?
Thanks
Say you have "the-package" installed at version 3.x and want to upgrade to 5.x
You would do this:
npm install the-package#5
it will update package.json and package-lock.json as well.
You can also update multiple packages in one command like npm install package1#5 package2#16
To check which packages need updates, run npm outdated
So, if I want to upgrade, what am I supposed to do?
In order to update major releases you can use the npm-check-updates.
See this great answer.
Or maybe I have just to remove the ^ character to let npm update do its job?
What is the common/best practice to adopt?
The most common/best practice is to never allow automatic updates to versions that have potentially breaking changes. Workflows are all over the map, from; manual test and then update packages.json, to fully automated detect, test, update and submission of packages.json.
Many Java/JavaScript environments are particularly sensitive to transitive dependency changes due to the lack of side by side versioning support. If your package brings in a breaking change of one of its own dependencies, then your package has introduced a breaking change to the system. If your 1.y.z causes an update of one of its dependencies from X.Y.Z to X+1.Y.Z it introduces a breaking change and is therefore not a stable version 1.y.z. Other packages that depend on the same package name as yours could potentially be broken whenever the developers of that package released a breaking change. Never let the world get into that state!
I recommend you study the Diamond Dependency Problem and take to heart. You should always carefully test breaking changes and never try to force them on your customers.
As pointed out by #ShaharShokrani, this answer gives a good workflow for manually updating your package. And to remain in compliance with SemVer 2.0.0 #8, don't forget to bump your own major version number.
You can also remove and install the package.
npm rm package
npm i package
How to safely npm install/update when deploying/upgrading ?
Problem 1 : npm install is a statefull operation that depends on the latest versions of dependencies in the time when the command is executed. This causes surprises when deploying since package.json file indicates ranges but not specific versions.
Problem 2 : everytime I make npm update or use ncu, I spend hours/days trying to handle incoherences between modules. Why would this happens in 2018 ?
Problem 3 : How to have package.json file that describes exactly the state of installed packages instead of ranges so that I can deploy without surprises ?
NB: I use Angular
If you use yarn or a more recent version of npm, it will generate for you a yarn.lock or package-lock.json.
This will keep exactly the version of any package when it's first installed, so further calls to yarn or npm install will fetch and install exactly those versions.
Of course you should add these lock files to your repository so anyone doing a fresh clone get the same dependencies installed.
See the npm docs: https://docs.npmjs.com/files/package-lock.json
And the yarn docs: https://yarnpkg.com/lang/en/docs/yarn-lock/
package.json file indicates ranges but not specific versions : Re-read the documentation, you can specify specific versions. See point 3 for an example.
Why would this happens in 2018 <= I/we can't speculate as to problems where you did not include any specific details, it might be a valid general gripe you have but StackOverflow is not the correct place to vent it.
Again, see the documentation. You just have to include the version number with an = sign. Example below would get only the version 5.0.0 of #angular/cdk.
"#angular/cdk": "5.0.0"
be advised that any call to npm update will update your package.json with the latest minor version, so setting a strict constraint version ex (5.0.0) will only work with npm install when no package-lock.json is present. When doing npm update, your 5.0.0 constraint will be replaced by a ^5.5.0 constraint (or whatever the next minor release is). It's fine if the packages you are using implement semver correctly, but you can have a lot of issues with breaking changes on minor release.