I have a package.json file where I have dependencies fixed to a particular version:
I had run npm install few days back and it generated the package-lock.json file. In the package-lock.json file, I can see that the exact version of eslint, i.e. v8.23.1, is installed but the sub-dependencies have a caret sign meaning it'll install the latest major/minor versions, e.g. #eslint/eslintrc= "^1.3.2":
After pushing my code, when the Jenkins build runs, it fails saying:
This is because a new version of #eslint/eslintrc is available and my package-lock.json has mapping of v1.3.2. I have two options in mind:
Update package-lock.json every time a sub-dependency gets upgraded but I'll have to do it quite frequently.
Lock dependencies using overrides field in package.json but this will also have to be updated frequently.
I want to freeze the dependencies (which I already did as seen in package.json) and also the sub-dependecies, until I decide to update them manually.
What should be done in this case?
My Node version is v16.15.0 and NPM version is v8.5.5.
The issue was with the node version. Earlier env.NODE_VERSION = '16 --lts' was being used. After setting it to v16.15.0, it worked fine. Thanks, #jonrsharpe :)
Related
We have an old legacy app, and a relatively small package we wanted to integrate in it. To make the whole process with less overhead as possible, we decided to do that by installing the package from the repo itself.
For example, our structure looks like that:
- BigApp
- SmallPackage
- package.json
- package.json
And so, the BigApp package.json has the following dependency:
SmallPackage: "file:./SmallPackage"
Now everything works great, up until we noticed that upon every npm install a new package-lock.json is created. That is an unwanted side effect since nothing has really changed.
I can't think of another reason for that but the fact that we used this local install path.
Can anywone come up with an idea why it happend?
Btw, I heard about npm ci - does it fit this scenario?
Thanks
package-lock.json is generated by default in recent versions of npm. It is not because you are installing from a local path or anything like that.
If you don't want the benefits of a package-lock.json file, you can run npm with --no-package-lock or put package-lock=false in a .npmrc file in the project root. You can also delete package-lock.json or you can ignore it.
npm ci depends on package-lock.json or npm-shrinkwrap.json, so if you want to use npm ci, you probably want the package-lock.json file.
I've read the documentation on Yarn, and I know the lock file is supposed to be committed to VC. See this and which explains at a high-level why the lock file is necessary, and this which lists a bunch of commands without much explanation of what they actually do!
I've also read a lot of questions on StackOverflow which asks about whether the lock file should be committed to VC.
However, all the documentation and SO threads seems to overlook the detail that I want to know, which is the following; What is the correct procedure (the correct bunch of commands to run) for:
Updating the yarn.lock file when I need to (i.e. in the development environment where I want to pull the latest minor versions and update the lock file to reflect this)
For keeping my lock file in sync with other developers to ensure that they are developing/testing from the exact same dependency versions, and
For updating/re-synching the node_modules directory on the production server (i.e. to ensure that the production server isn't running on a different/breaking version of dependent packages)
I ask partly because in the past while doing a git pull on the server, I've faced messages telling me that the yarn.lock file has been updated independently of the development/VC process. As far as I'm concerned, this should never be allowed to happen.
the following information are based on what we use daily at Orange, this may be not the single truth.
1 ) Updating yarn.lock
yarn upgrade [package | package#tag | package#version | #scope/]... [--ignore-engines] [--pattern]
This command updates dependencies to their latest version based on the version range specified in the package.json file. The yarn.lock file will be recreated as well.
source : https://yarnpkg.com/en/docs/cli/upgrade
2) Dependency between developers
What i suggest you to do is to create a script that will check the current 'recomended' version to have with the help of:
yarn check
Verifies that versions of the package dependencies in the current project’s package.json match those in yarn’s lock file.
source : https://yarnpkg.com/en/docs/cli/check
3) Updating server production
The same as 2 ) using a git hook script, should help you to yarn check if the package.json version are correct if not launch a yarn update.
Honestly, this is a matter of opinion/preference. I have seen a few strategies:
Using yarn upgrade
Manually bumping the version in package.json before running yarn
Like Fabien mentioned: use yarn check
You can use yarn offline mirrors where you commit caches of your npm packages into version control. (See this medium article)
Plus there are lots of upsides when using yarn --offline:
Builds are faster because you don't have to fetch packages from the npm registry.
Your builds will fail if you do not have the right dependencies.
I got what package-lock.json is standing for, but I don't understand how is caret range work after adding this file?
Say I have a package (my-module) that I want to have all new non-breaking versions without specifying new versions manually. I install latest version and this is the result in package.json file:
"my-module": "^4.1.1"
However package-lock.json is also getting updated with fixing the version of my-module to 4.1.1.
Next time a new version comes out of my-module: 4.1.2. Running npm i will not install it as the version in package-lock.json is fixed to the old version.
Question
How can I achieve that npm i will download latest non-breaking version of my-module without creating new package-lock.json file all the time? Did this file just invalidate using caret range?
We came up with the idea of using preinstall functionality of package.json.
So under in your package.json file under scripts tag you add:
"preinstall": "npm update".
Since npm update only updates packages affected by the caret range syntax you can have both package-lock.json and latest updates.
While I'm not fond of just posting pieces of documentation verbatim, I feel it is the best source to explain why what you're asking for is exactly what package-lock.json was designed to NOT NECESSARILY DO:
package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json.
It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
WHEN package.json is fed into npm i the result of the operation is a filesystem node_modules, consistent with all the dependencies as declared in the package.json file.
This operation DOES NOT produce the same result all the time: even when using the exact same package.json file. And there are good reason why npm i was designed to do this, specifically:
If a new version of a direct semver-range package may have been published since the last time your packages were installed, and thus a newer version will be used.
How does yarn work when it encounter a ^ (caret) in package.json dependencies?
Let's say I have react: ^16.0.0 and when I yarn install, it will create a lock on that version (16.0.0).
Now sometime later when react 16.1.0 is released, and I yarn install again with the lock file, will yarn upgrade it to that version or follow what is in the lock file which is 16.0.0?
Thanks.
yarn install will install the exact version in the lockfile. That's the great benefit of a lockfile, everyone working on your project gets the exact same version of the package regardless of when the do yarn install. (e.g. I do yarn install today, when 16.0.0 is the current version, but you do yarn install tomorrow when 16.1.0 is the current version. We'll still both get 16.0.0 because that's what our lockfile says we should get. Our development environments are exactly the same, which is what we want. Likewise if we deploy in 2 weeks when 16.2.0 is the current version, 16.0.0 will get deployed; thus our dev and prod environments are exactly the same, too)
If 16.1.0 is released and you want to update your project to use it, use yarn upgrade. Note that you can upgrade all of your packages, or just one specific package, as well as update to the latest version of a package or a specific version of a package. https://yarnpkg.com/lang/en/docs/cli/upgrade/
Version Control Your package.json and yarn.lock
By adding these two files to version control, you'll easily be able to revert your project to a specific point in time in regards to your packages.
The selected answer is wrong.
caret means following
^3.1.4 will allow a version range from >=3.1.4 <4.0.0
I have a deployment process where I check code into a git repository, and via web hooks a deployment script is run on the production server. On that server, I connect to git using ssh and a .pem key, pull from git, npm install, build webpack and restart the service process.
I never intend to commit anything from the prod servers - they should be able to deploy automatically. However, this does not work, because the package-lock.json file is frequently updated when I run npm install, and so the next time I deploy, the git pull step fails, saying that I conflict with existing package-lock.json file because it has changes that are not committed.
My current solution is to .gitignore the package-lock.json file. But that defeats its purpose, to provide builds that are identical to the ones on my dev machine.
What would be the right way to handle package-lock.json?
There's a helpful StackOverflow Question/Answer about why your package.lock is changing. The closest most useful answer seems to reference an NPM bug that's seeing much activity here in October 2017.
But currently, package.json overrides package-lock.json, meaning if you use ~2.1 and there's a 2.2 version of that package, your production deploy will get upgraded.
Assuming you're not from the future, there's two different ideas here:
Use only non-prefixed, specific version numbers (2.1 vs ~2.0) in your package.json. (This is not great)
npm install --no-save... which doesn't solve the underlaying issue of lock files getting ignored, but I think will keep the package-lock.json from being updated.