fix(pnpm): lockfile v6 is supported as low as version 7.24.2

[dweitzman]

Changes

Allow pnpm versions as low as 7.24.2 with pnpm lockfile version 6 (https://github.com/pnpm/pnpm/releases/tag/v7.24.2)

Context

We haven't upgraded to pnpm 8 yet but we do have a v6 lockfile, which is hitting trouble with the renovate-assumed pnpm version constraint.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[RahulGautamSingh]

Won't we need to change the install command as well? As mentioned in the release you linked.

[dweitzman-codaio]

Won't we need to change the install command as well? As mentioned in the release you linked.

The specific issue we're hitting is this when renovate runs:

No matching or stable tool versions found - using an unstable version (repository=XYZ, branch=renovate/pin-dependencies)
       "toolName": "pnpm",
       "constraint": "<7.33.0 >=8",

The 7.33.0 comes from our package.json file:

  "engines": {
    "node": ...,
    "pnpm": "<7.33.0"
  }

My assumption is that the 8 is coming from this code and that with no further changes renovate will be willing to install and use 7.32.x once it's not being asked to fulfill an impossible constraint

[dweitzman-codaio]

Won't we need to change the install command as well? As mentioned in the release you linked.

Or was the question here whether pnpm is willing to read a lockfile and keep the version even pre-pnpm 8? I think it'd happily read a v6 lockfile from 7.x even if it defaults to writing a lower lockfile version sometimes for new lockfiles

[RahulGautamSingh]

I mean the writing part. If it reads a v6 lockfile and we use the existing command pnpm install --lockfile-only dep@x.x.x to generate a new lockfile, will the newly generated lockfile be of v6 or v5.4?

Cause in the release its mentioned that to generate a v6 lockfile, we need to:

To use the new lockfile format, use the use-lockfile-v6=true setting in .npmrc. Or run pnpm install --use-lockfile-v6

[rarkins]

hopefully if the existing lock file is v6 it retains v6. But lock file maintenance in this case would probably fail

[RahulGautamSingh]

I think it will depend on whether we delete the lockfile prior to regenerating it. I tried on replit, and when existing lockfile has v6 the version is retained but when creating a new one v5.4 was generated.

[dweitzman-codaio]

hopefully if the existing lock file is v6 it retains v6. But lock file maintenance in this case would probably fail

Here's a unit test from the lockfile implementation PR for that release (https://github.com/pnpm/pnpm/pull/5810/files#diff-7a5adfdd88aa5f07a6a1565961975b0b31d34186446382fa34e98b219d0b78c9):

test('lockfile v6', async () => {
  prepareEmpty()

  const manifest = await addDependenciesToPackage({}, ['@pnpm.e2e/pkg-with-1-dep@100.0.0'], await testDefaults({ useLockfileV6: true }))

  {
    const lockfile = await readYamlFile<any>(WANTED_LOCKFILE) // eslint-disable-line @typescript-eslint/no-explicit-any
    expect(lockfile.lockfileVersion).toBe('6.0')
    expect(lockfile.packages).toHaveProperty(['/@pnpm.e2e/pkg-with-1-dep@100.0.0'])
  }

  await addDependenciesToPackage(manifest, ['@pnpm.e2e/foo@100.0.0'], await testDefaults())

  {
    const lockfile = await readYamlFile<any>(WANTED_LOCKFILE) // eslint-disable-line @typescript-eslint/no-explicit-any
    expect(lockfile.lockfileVersion).toBe('6.0')
    expect(lockfile.packages).toHaveProperty(['/@pnpm.e2e/pkg-with-1-dep@100.0.0'])
    expect(lockfile.packages).toHaveProperty(['/@pnpm.e2e/foo@100.0.0'])
  }
})

It looks to me like lockfile v6 is testing that when the lockfile was previously v6, adding a dependency maintains v6 without the need for explicitly setting useLockfileV6 on the future addDependenciesToPackage() call like it was set on the first call

[github-actions]

Hi there,

Get your issue fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.

To get started, please read our guide on creating a minimal reproduction.

We may close the issue if you, or someone else, haven't created a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team

[renovate-release]

🎉 This PR is included in version 35.110.1 🎉

The release is available on:

• GitHub release
• 35.110.1

Your semantic-release bot 📦🚀

[viceice]

Won't we need to change the install command as well? As mentioned in the release you linked.

The specific issue we're hitting is this when renovate runs:

No matching or stable tool versions found - using an unstable version (repository=XYZ, branch=renovate/pin-dependencies)
       "toolName": "pnpm",
       "constraint": "<7.33.0 >=8",

The 7.33.0 comes from our package.json file:

  "engines": {
    "node": ...,
    "pnpm": "<7.33.0"
  }

My assumption is that the 8 is coming from this code and that with no further changes renovate will be willing to install and use 7.32.x once it's not being asked to fulfill an impossible constraint

can you create a minimal reproduction repo and open a discussion with it? it seems we need to add additional checks, when the engines or packageManager already defines a proper pnpm version to use. in that case we shouldn't add any additional constraints.

[rarkins]

I think we need to use "subset" from semver

[Gritme]

Yes