I'm having issues with a NPM and couple of dependencies where the latest version of a package that NPM finds is different from the latest version that is actually present in the NPM repo.
I'm trying to install a package that has other dependencies, but I'm unable to because I get the "No matching version found for (package)#(version)" error. However, if I go to the NPM official site, I can see that there is in fact matching version for the package I need.
I've upgraded NPM to its latest version and I have also cleaned my NPM cache.
Edit: Some of the specific packages in question - gulp-chmod#^2.0.0, sanitize-filename#^1.6.1, generator-code#1.1.22
See if the adding the following key in package.json helps you!
"engines": {
"node": "8.1.1",
"npm": "5.0.3"
}
We can specify the node and npm version in the package.json file as shown above.
In getting the same error (for a package I just updated, typeson) and looking at my log, I see it is trying to access:
https://registry.npmjs.org/typeson
While this and https://www.npmjs.com/package/typeson are showing only up to 5.17.0, http://registry.npmjs.org/-/v1/search?text=typeson is showing the currently latest version, 5.18.0.
Maybe it can just take time to propagate through the site.
Update: In my case, it still wasn't working about an hour later, so I published a new version, and it was then immediately available.
Related
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
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.
Imagine the situation:
We have a project with node_modules gitignored. While fixing a task developer1 updated package.json to newer version of some module, e.g.
"dependencies": {
"async": "^1.5.2", // was 1.5.1
...
Then he runned npm install locally to get updated module, performed tests, finished task and pushed changes on the server.
Developer2 pulled changes from server and get app broken because still having previous version of async locally (1.5.1). And developer2 can waste a huge amount of time finding what's exactly goes wrong. Until they do npm i.
Can you suggest any npm package or ready-to-use hook that can check versions in package.json against actual versions of node_modules ?
It will be really helpful!
PS: I'm aware of https://www.npmjs.com/package/npm-check but it does not do what I need.
The package check-dependencies might do what you want.
$ check-dependencies
url-loader: installed: 0.5.8, expected: 0.4.0
Invoke npm install to install missing packages
At my current day job we had exactly this problem.
We fixed it by creating an easy script that pulled the new source and after that directly executes npm update.
I have already seen this question npm-install-vs-update-whats-the-difference
My question is around using install vs update for private github repo using git+ urls.
I have a private github repo which is used in the grunt. This repo receives frequent updates. I installed this repo using git+ssh url as mentioned here npm install git remote url
Everything works fine when installing. Problem comes when updating the package. As per my understanding and question mentioned above, npm updates the package to latest version when doing npm install but this doesnt seem to be case with package installed from github. I had to use npm update to get the latest version. I dont mind using npm update but I have observed that its slow compared to npm install. Can anyone put their thoughts why this might be happening.
My package.json looks like following
{
"name": "My Project",
"version": "1.0.0",
"dependencies": {
"grunt": "^0.4.5",
//Relevent package
"my-tasks": "git+ssh://git#github.com:Flutterbee/my-tasks.git"
}
}
PS : Using npm 3.3.3 (if that makes difference)
Can you try with specifying the branch name with in your package.json like this
"my-tasks": "git+ssh://git#github.com:Flutterbee/my-tasks.git#master"
I have a project with a local file dependency in my package.json like this:
"dependencies": {
"dep_1": "file:../../dep_1"
}
}
When I do npm install it is installed into node_modules. But if I make changes to dep_1 how do I update the module version in node_modules?
I tried doing npm update but nothing happens.
If you are using a relatively new version of npm (I used version 2.14.2) you can bump the version number in package.json and npm update dep_1 should work. Otherwise how can npm know that something needs to be updated?
Note: This will only work if the version is higher than what has previously been installed. You will have to clean the cache to reset this behaviour.
However, you can forceably (and lazily) update local modules by simply running npm install again. e.g.
npm install dep_1
It should be fast since its on your local computer and you don't have to play around with version numbers.
For more detail see the discussion about this issue on the official npm repository page: https://github.com/npm/npm/issues/7426