Skip to content

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

Closed

Description

@JustinBeckwith

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

Activity

  1. added
    manager:npmpackage.json files (npm/yarn/pnpm)
    priority-1-criticalA bad bug or work that is holding up a lot of other important features or fixes
    on Jan 11, 2021
  2. viceice commented on Jan 11, 2021

    @viceice
    Member

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

  3. viceice commented on Jan 11, 2021

    @viceice
    Member

    No, it because we install latest npm after installing node in buildpack. 🤦‍♂️

    So we have npm v7 in all latest node images. 😱

  4. rarkins commented on Jan 11, 2021

    @rarkins
    Contributor

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

  5. rarkins commented on Jan 11, 2021

    @rarkins
    Contributor

    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

  6. JustinBeckwith commented on Jan 11, 2021

    @JustinBeckwith
    Author

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

  7. rarkins commented on Jan 11, 2021

    @rarkins
    Contributor

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

  8. rarkins commented on Jan 11, 2021

    @rarkins
    Contributor

    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.

  9. added a commit that references this issue on Jan 12, 2021
    08a187a
  10. renovate-release commented on Jan 12, 2021

    @renovate-release

    🎉 This issue has been resolved in version 24.16.1 🎉

    The release is available on:

    Your semantic-release bot 📦🚀

  11. locked as resolved and limited conversation to collaborators on Feb 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    manager:npmpackage.json files (npm/yarn/pnpm)priority-1-criticalA bad bug or work that is holding up a lot of other important features or fixes

    Type

    No type

    Fields

    Priority

    None yet

    Datasource

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions