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.
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
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
There are 2 versions of node.js - LTS and latest current version. When using npm install to install packages, are the packages installed independent of the node.js being used? Do different node.js versions install different versions of the packages?
No they don't. When you install a npm package, it has its own version but of course package's version and node's version affect the usability of these packages.So, you need to delete old version of node from your system files. One more thing, please do not install npm packages global.Because when you do that, next time maybe you can use it in a other project but when it is updated by creater, you won't be able to have new updates and features or as I said before it can't be compatible with the new version of node.
I found different versions in package.json file, than versions returned by executing command-npm ls depth=0. I want to create lock file which will show the exact/fixed versions of installed npm packages
NPM as of version 5 automatically creates a package-lock.json file for you, which should do what you need.
If you're concerned about using specific package versions, I also recommend modifying your package.json to remove the semver caret (^, e.g. ^3.0.0 -> 3.0.0) from each package version number. This ensures that the same version is always downloaded until you explicitly upgrade the package.
I've installed nodenv to manage versions of node and npm in my pc. Because when I try install packages like , angular-cli, webpack , typescript, angular2 and another, I get errors
FIRST QUESTION: Can an version node or npm produce error when i install a package?
Some packages tells things like: "The generated project has dependencies that require Node 4.x.x and NPM 3.x.x."
but they don't mention the exact version. by example Can a version of node 4.1.5 produce errors and not the version 4.0.5 ?
SECOND QUESTION:
I don't like these packages need be installed like global (-g) and the problems i see sometimes there are conflicts between global packages installed.
Example error:
npm WARN EPEERINVALID string-replace-loader#1.0.3 requires a peer of webpack#1.x.x || 2.x.x but none was installed.
PhantomJS not found on PATH
Downloading https://github.com/Medium/phantomjs/releases/download/v2.1.1/phantomjs-2.1.1-macosx.zip
but what about if two global packages use same global package, but some of they use a different version for every package?
Its up to npm package owners to define in their package.json all the upstream dependencies with a set of working versions which play well together ... challenge is as a package owner to make your package.json loose as possible regarding upstream dependencies to enable pulling in newer releases of these dependent packages yet tight enough that your published package still works
Often this is not the case which can lead to version mismatch invoked errors ... if possible always use most recent package releases this goes for nodejs itself as well
When package.json mentions versions such as 3.x.x it means it should work with any value of x.x so just chose the highest number to fit the pattern
Where possible avoid doing a global install unless it is for command line executables ... this is especially true for packages which your code pulls in as opposed to an executable centric package
UPDATE I am now able to successfully install this
npm install -g angular-cli
using the latest release of node
node --version
v6.5.0
so I suggest you upgrade your own project code and node version to avoid that pinned release which fails and work with the most current releases