Out of curiosity, if you are running nmp install within your CI/CD pipeline, would inconsistencies between package.lock and package.json not be picked up there? And if so, what’s the benefit of this?
This is assuming that a package-lock.json file exists. Some projects (like most of mine) opt out of this because it adds maintainer burden for no tangible benefit, at least in the case of modules. It's definitely recommended for applications, but since package-lock.json doesn't get published to the registry there's really very little point to keeping it around.
That said, as far as I know (and I could totally be wrong!) you can still have unmet dependencies that wouldn't be caught between package-lock.json and package.json.
Indeed it does, but it’s an antiquated approach that I try to keep out of my open-source packages.
IMO the cost of maintaining an npm-shrinkwrap.json is higher than writing high-quality code that will be resilient enough to handle dynamic dependency resolution.
If I am feeling especially picky about a certain module or set of modules, I’ll generally pin the versions in my projects’ package.json
George, if you have inconsistencies between the package manifest and the package lock, an npm install or a yarn install will produce different install results. Meaning to say, the lockfile will not be used as the source of truth.
Exactly for that you should actually use npm ci in order to force the lockfile.
I wrote about it in short here: dev.to/lirantal/so-you-think-youre...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Out of curiosity, if you are running
nmp installwithin your CI/CD pipeline, would inconsistencies betweenpackage.lockandpackage.jsonnot be picked up there? And if so, what’s the benefit of this?This is assuming that a
package-lock.jsonfile exists. Some projects (like most of mine) opt out of this because it adds maintainer burden for no tangible benefit, at least in the case of modules. It's definitely recommended for applications, but sincepackage-lock.jsondoesn't get published to the registry there's really very little point to keeping it around.That said, as far as I know (and I could totally be wrong!) you can still have unmet dependencies that wouldn't be caught between
package-lock.jsonandpackage.json.shrinkwrap.jsongets published :vIndeed it does, but it’s an antiquated approach that I try to keep out of my open-source packages.
IMO the cost of maintaining an
npm-shrinkwrap.jsonis higher than writing high-quality code that will be resilient enough to handle dynamic dependency resolution.If I am feeling especially picky about a certain module or set of modules, I’ll generally pin the versions in my projects’
package.jsonIt doesn't matter what kind of code you write if your dependencies introduce bugs or change published API with a patch version :D
You could not include those dependencies 😂
Be serious 😂
George, if you have inconsistencies between the package manifest and the package lock, an
npm installor ayarn installwill produce different install results. Meaning to say, the lockfile will not be used as the source of truth.Exactly for that you should actually use
npm ciin order to force the lockfile.I wrote about it in short here: dev.to/lirantal/so-you-think-youre...