Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

package-lock.json changes lockfile version via npm 7 #8253

Closed
JustinBeckwith opened this issue Jan 11, 2021 · 8 comments · Fixed by #8254
Closed

package-lock.json changes lockfile version via npm 7 #8253

JustinBeckwith opened this issue Jan 11, 2021 · 8 comments · Fixed by #8254
Labels
manager:npm package.json files (npm/yarn/pnpm) priority-1-critical A bad bug or work that is holding up a lot of other important features or fixes type:bug Bug fix of existing functionality

Comments

@JustinBeckwith
Copy link

JustinBeckwith commented Jan 11, 2021

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

image

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).

cc @bcoe @chingor13

@rarkins rarkins added manager:npm package.json files (npm/yarn/pnpm) type:bug Bug fix of existing functionality priority-1-critical A bad bug or work that is holding up a lot of other important features or fixes labels Jan 11, 2021
@viceice
Copy link
Member

viceice commented 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
Copy link
Member

viceice commented 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
Copy link
Collaborator

rarkins commented Jan 11, 2021

I thought it's because we pick node 15 when the package.json constraint is >= something

@rarkins
Copy link
Collaborator

rarkins commented 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
Copy link
Author

If the answer here is to require specifying engines: { npm: "6" } in package.json, that would be a reasonable requirement from our perspective 🤷

@rarkins
Copy link
Collaborator

rarkins commented 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
Copy link
Collaborator

rarkins commented 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.

@renovate-release
Copy link
Collaborator

🎉 This issue has been resolved in version 24.16.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
manager:npm package.json files (npm/yarn/pnpm) priority-1-critical A bad bug or work that is holding up a lot of other important features or fixes type:bug Bug fix of existing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants