During docker vulnerability check we found that package minimatch has vulnerabilities. Due to this we have to use minimatch package to latest which is 3.0.4.
I have copied the package-lock.json in the js section of fiddler https://jsfiddle.net/Loecjuy4/1/
"minimatch": "3.0.4" instead of "minimatch": "2.0.10"
If you search the package-lock.json at fiddler link that I provided, you will find minimatch as dependencies in many places sometimes version 3.0.4 is used (line 2022 in eslint) while in other places version 2.0.10 is used (line 3170).
I want to know a way such that package minimatch has the same version 3.0.4 in all the places of package-lock.json. I have tried shrinkwrap but it too shows different version of minimatch.
Update all your dependencies to the latest version. If the old version is still in your package-lock.json, it means that the dependencies you use have a dependency itself on the old version. You should then probably contact the maintainers of these packages to upgrade their dependencies (i.e. by opening an issue on their respective repository).
Related
This is the scenario:
I have a package, say package-a that depends on package-b. I have version 2.0.0 of package-a depends on version 1.1.0 of package-b. I specified this dependency using the notation: ^1.1.0. I generated the lock file and then the shrinkwrap. I then publish package-a to the repository.
My understanding is that the above ensures that whenever version 2.0.0 of package-a is installed it will always use version 1.1.0 of package-b even if there are newer version of package-b.
This does not seem to be the case, because when I bumb package-b to 1.2.0, then I deleted package-a and re-installed it, when I check its node_module, I see it installs version 1.2.0 of package-b with it (instead of 1.1.0 that is specified in the shrinkwrap file)
How to I fix this? How do I ensure that my package will always install what is found in the shrinkwrap file?
Or maybe I understand how the nom shrinkwrap file should work? If so an explanation of why what I did, did not work. I would appreciate pointers on how to also make it work as I want
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.
I want to lock all versions in package.json, but when I change a version from "^X.Y.Z" to "X.Y.Z" and install packages again, some features break because of older versions. I want to retrieve all versions of installed packages with ^X.Y.X.
Is there a way to update the package.json file for the installed node_modules.
There is a SO thread but can't find a helpful answer.
Update
I'm just currious if their is a utility library to do that labor work for me because in case of huge dependencies list I have to do npm view version for each pkg and then update the obtained version in package.json.
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
As of this writing, the current version of #babel/core published to npm is 7.2.2. The latest "release" version of babel on github is 7.3.1, which contains several fixes I'm interested in.
What is the correct syntax to install the latest github version of #babel/core via package.json? I tried
"devDependencies": {
"#babel/core": "github:babel/babel#v7.3.1"
}
and some variations thereof but those gave me "invalid package version". I think I'm confused about how to deal with the #scope syntax?
As of 26 Jan 2019 -
#babel/core is released as 7.2.2,
therefore, there is an invalid package version when installing git+https://git#github.com/babel/babel.git#v7.3.1.
the relevant packages for 7.3.1
would be babel-helpers/babel-plugin-proposal-object-rest-spread and babel-preset-env,
which you would have to install separately from #babel/core
The discrepancy between #babel/core version
and other packages is to ensure modularity of packages within the #babel team.