What is the correct use of package.lock.json file, when exactly it works - npm

What is the exact use of package.lock.json file? I have read about it but it's confusing.
Let's say I do npm install so that it will create a package.lock.json file, and the next time when I do npm install, will it retain installation of the same packages as it was mentioned in the package.lock.json file?
Let's say I have a package version defined as "^1.0.0" in my package.json file and a new version becomes available in the npm registry. Will it update the package when I do npm install, or will it keep the same as what was there in the package.json?
Is there any easy way to update the package.json file with the exact no of package version without manually updating it one by one? I want to keep maintain the version of the package the same so that next time anybody does npm install, they should get exactly the same package. It's need for a release branch
Actually I need what was the original definition of package.lock.json file but I found inconsistency in its behavior.
I tried using NPM CI but it fails with error node_gyp needs python https://github.com/nodejs/node-gyp/issues/1977

What is the exact use of package.lock.json file?
Ans: The file is used to describe the exact tree that was generated initially, that is the version of the dependency that was used initially to install (NOTE: It will always be modified if package.json or node_modules are modified by npm)
source: https://docs.npmjs.com/configuring-npm/package-lock-json.html
Now coming to your specific questions :
Let's say I do npm install so that it will create a package.lock.json file, and the next time when I do npm install, will it retain installation of the same packages as it was mentioned in the package.lock.json file?
The simple answer here is: Yes
When you do npm install initially, you specify the package name. npm will create node_modules folder and package-lock.json file and the entry of the package with the version that was used to install will be added. next time when you do npm install, without specifying the package it will not update any of your package even with the caret (^) symbol because this time npm will look at the package-lock.json file (as it is present there) and it will install the same version that is specified in the (package-lock.json) file.
Let's say I have a package version defined as "^1.0.0" in my package.json file and a new version becomes available in the npm registry. Will it update the package when I do npm install, or will it keep the same as what was there in the package.json?
As explained in first question, it will not, if the package-lock.json is present in the directory. Updating of the package will only happen if package-lock.json file and node_modules folder are not present in the directory.
Is there any easy way to update the package.json file with the exact no of package version without manually updating it one by one? I want to keep maintain the version of the package the same so that next time anybody does npm install, they should get exactly the same package. It's need for a release branch
It is a good practice to use npm ci, but you can also use npm update, this will update the dependencies to its latest minor version, and your package.json as well as package-lock.json file will also be updated
For the production, its preferred way to use the same version of dependencies that was used initially. In this case it is better to have package-lock.json file, so in case of dockerizing application when you do npm install it will install the dependencies with versions that are used in package-lock.json

Related

package.json and package-lock.json does not reflect node_module's versions

I updated my Angular project with npm and for some reason package.json and package-lock.json was not updated accordingly. So the question is, do I have to update them manually, or is there a way to update these files according to the actual versions in node_modules?
I tried npm init but that gives me a very big package.json containing every package in node_modules. Therefore I would prefer something that updates each entry in package.json according to what is actually installed.
I had a similar problem, where not all of the needed modules in node_modules were "required" (directly or indirectly) by package.json, so every time I installed something using npm install, it also removed a whole bunch of modules.
My solution wasn't a very satisfactory one, but it did the trick:
Renamed my package-lock.json file and package.json files to keep them safe but out of the way.
Used npm init as you mentioned, to create a version of package.json that contained all of the modules in node_modules.
Moved that out of the way but kept it for reference.
Renamed node_modules to something else to keep it safe but out of the way.
Created a brand new package.json file, again using npm init, but which had no dependencies because there was now no node_modules directory.
Went through my source files finding every dependency require statement, and did an npm --save install package#version on each. I got the package name from the require and then found it in the complete package.json (from steps 2 and 3) and used the version number from that to ensure it matched what was there before. (I've got some legacy code with out-of-date modules, which is why I wanted specific versions.)
Now, my package.json file is minimal, but when I run npm install, everything is up to date.

How to upgrade one individual file from node_modules folder instead of upgrading the whole package

I need to upgrade one of the yarn.lock file from node_modules folder to remove the Raven vulnerabilities issue.
The file path is
src/node_modules/form-data/yarn.lock
I know I can use npm install to install a new package. But is there a way that I can keep the whole package to the current version, but upgrade one file in the package?
You can edit the file directly. Or you can fork the package and update just the file, then publish your fork. But no, there is no way to use npm (and presumably not yarn either) to update a file without updating the package. That is by design. There are big debugging and malware possibilities if you run an npm command and have it report back that you are running version 1.2.3 but in reality you are running version 1.2.3 with one or more files modified.
I'm puzzled a bit by your desire to update a yarn.lock file in a package. yarn.lock files don't affect anything if they're inside node_modules. This is true both for npm and yarn. The yarn.lock file is ignored if it is not in your top-level project. Updating yarn.lock inside node_modules won't do anything to your running code. Perhaps the dependency is listed in your top-level yarn.lock file for your project?

"npm i" does not respect the package-lock.json file, fetches bad version and changes file

The package-lock.json file has the particular version of a package, however after running "npm i" a later version is installed, and the package-lock.json file has been updated to reflect the later version.
Why is this happening? I thought the package-lock.json file was the absolute source of truth.
How to prevent it?
Maybe you meant
npm ci
The npm i is a short form for npm install which uses the package.json file.
ci stands for continuous integration and should never update automatically but use the package-lock.json, which itself will be generated.

How to override package.json "latest" dist-tag with version from package-lock.json?

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.

Package.json pasting a package name in bad?

What happens differently when you go into your package.json and paste a package name in and do npm i vs. doing it the real npm i package-name?
package.json:
"dep": 1.0.0
vs
npm i dep --save
We have a build error and learned can bypass it by pasting. I know it isn't kosher but I really want to know why and what consequences that causes?
npm install dep doesn't add the dependency to the package.json file.
You have to add --save or --save-dev to add it to the package.json file.
Besides that, npm install will always serve you the latest build (in most cases the version tagged as latest (see npm docs)), unless you specify a specific version.
If you want your lock file to update, you have to delete the file before running npm install to generate a lock file with the dependency included (for more info check out this GitHub issue)
In conclussion it shouldn't make much of a difference if you manually add the dependency to package.json file and install it with npm install, unless the latest version of your dependency is broken.