You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
package-lock.json changes lockfile version via npm 7 #8253
We enabled lock file updates for node.js projects in one of our repos, and noticed that the PR updates the lockfile version from v1 to v2: googleapis/repo-automation-bots#1270
Ideally, lock file maintenance would keep using the same version of npm/node we used to generate the lock file. In the absence of that, at least using latest LTS feels like a reasonable strategy. I believe what's happening today is you're using npm 7.x, which writes the v2 lock file format. npm 7.x is shipped with node.js 15.x and up. The latest 14.x release of nodejs still rolls with npm 6.x, which writes a v1 lockfile.
As of now, I don't want to accept this renovate PR because it would introduce a format that npm 6.x does not absolutely know how to correctly read (as far as I know).
Activity
viceice commentedon Jan 11, 2021
@rarkins i think we fallback to latest node, because they don't have any engine defined.
Maybe we need to revert our latest node to v14.
viceice commentedon Jan 11, 2021
No, it because we install latest npm after installing node in buildpack. 🤦♂️
So we have npm v7 in all latest node images. 😱
rarkins commentedon Jan 11, 2021
I thought it's because we pick node 15 when the package.json constraint is >= something
rarkins commentedon Jan 11, 2021
Latest npm should still be 6 but we may soon have a challenge once it becomes 7. But we can look at the lock file version to decide.
We could specify node tagScheme instead of npm however I don't think that will prevent node 15 from being chosen
JustinBeckwith commentedon Jan 11, 2021
If the answer here is to require specifying
engines: { npm: "6" }inpackage.json, that would be a reasonable requirement from our perspective 🤷rarkins commentedon Jan 11, 2021
@JustinBeckwith yes I think that would solve it, but let me double check it first in a test repo before you change so many files.
rarkins commentedon Jan 11, 2021
I can confirm that's one way to solve it, however I have a fix in #8254 which I can put live tomorrow and you can refresh the PR once that's ready.
fix(npm): don’t pick node 15 unnecessarily (#8254)
renovate-release commentedon Jan 12, 2021
🎉 This issue has been resolved in version 24.16.1 🎉
The release is available on:
24.16.1Your semantic-release bot 📦🚀