4 ms·
Every time you commit, package-lock.json is different. And when it is not, then I have 26 new vulnerabilities to be fixed by “npm audit fix”. I have zero trust
by laurent92 5y ago
Every time you commit, package-lock.json is different. And when it is not, then I have 26 new vulnerabilities to be fixed by “npm audit fix”. I have zero trust in my build being reproducible, or even working one year forward.
- rewma 5y ago> Every time you commit, package-lock.json is different. And when it is not, then I have 26 new vulnerabilities to be fixed by “npm audit fix”. I have zero trust in my build being reproducible, or even working one year forward. In some of the nodejs projects I've worked, we had allu dependencies with pinned version numbers, and each week we created a ticket to track work on upgrading them. This typically involved a single commit updating package versions and running all tests. More often than not it took no work at all. If a project just lets their dependencies change randomly and does not invest any work updating them, of course there's bound to be pain and suffering.
- dymos 5y agoIf your package-lock changes every commit (I'm guessing this means it changes after every `npm install`) then you might have some issues within the team in terms of consistent npm/node versions, or perhaps with the registry you're using if it isn't the public registry. In my previous role we constantly ran into issues with the integrity hash changing which was an unfortunate side effect of both the issues I mentioned above, an Artifactory npm registry and inconsistent npm/node versions TL;DR though, it's not normal for the package-lock to change all the time.
- jschroeder228 5y agoDocker? That gives you immutable images to deploy. The flip side is a language like clojure, which I love, but the deps are updated at a glacial pace.
- cutler 5y agoIsn't that one of Clojure's selling points?