Support pnpm v9 lockfiles

[viceice]

Describe the proposed change(s).

pnpm v9 brings a new lockfile format 9.0 which is different from 6.0

https://github.com/pnpm/pnpm/releases/tag/v9.0.0

[viceice]

wrong behavior: renovate-reproductions/28467-pnpm-v9@d51e853

[viceice]

@rarkins I think i found a bug

renovate/lib/workers/repository/updates/generate.ts

Lines 341 to 343 in 0a43865

	config.reuseLockFiles = config.upgrades.every(
	(upgrade) => upgrade.updateType !== 'lockFileMaintenance',
	);

renovate/lib/modules/manager/npm/post-update/index.ts

Lines 229 to 235 in 0a43865

	// istanbul ignore next
	if (
	packageFile.managerData.pnpmShrinkwrap &&
	config.reuseLockFiles === false
	) {
	await deleteLocalFile(packageFile.managerData.pnpmShrinkwrap);
	}

this will delete the lockfile before we get to the update function, so we can't extract contraints from lockfile here

renovate/lib/modules/manager/npm/post-update/pnpm.ts

Lines 145 to 149 in 0a43865

	const lockfileContent = await readLocalFile(lockFileName, 'utf8');
	if (!lockfileContent) {
	return null;
	}
	// TODO: use schema (#9610)

[viceice]

We delete the lockfile here if it's lockfile maintenance

renovate/lib/modules/manager/npm/post-update/pnpm.ts

Lines 105 to 118 in 0a43865

	if (upgrades.find((upgrade) => upgrade.isLockFileMaintenance)) {
	logger.debug(
	`Removing ${lockFileName} first due to lock file maintenance upgrade`,
	);
	try {
	await deleteLocalFile(lockFileName);
	} catch (err) /* istanbul ignore next */ {
	logger.debug(
	{ err, lockFileName },
	'Error removing yarn.lock for lock file maintenance',
	);
	}
	}

[renovate-release]

🎉 This issue has been resolved in version 37.303.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 37.303.0

Your semantic-release bot 📦🚀

[moltar]

I think something here has introduced a bug. We use a self-hosted version via GH Actions, and for the past 3 days pretty much all PRs fail to update pnpm locks. Our action does not pin a Renovate version, so it always uses the latest tag.

 WARN: artifactErrors (repository=foo/bar, baseBranch=master, branch=renovate/undici-6.x)
       "artifactErrors": [
         {
           "lockFile": "pnpm-lock.yaml",
           "stderr": "Scope: all 3 workspace projects\nProgress: resolved 1, reused 0, downloaded 0, added 0\nProgress: resolved 77, reused 0, downloaded 0, added 0\nProgress: resolved 417, reused 0, downloaded 0, added 0\nProgress: resolved 631, reused 0, downloaded 0, added 0\nProgress: resolved 957, reused 0, downloaded 0, added 0\nProgress: resolved 1028, reused 0, downloaded 0, added 0\nProgress: resolved 1411, reused 0, downloaded 0, added 0\nProgress: resolved 1591, reused 0, downloaded 0, added 0\nProgress: resolved 1685, reused 0, downloaded 0, added 0\nProgress: resolved 1685, reused 0, downloaded 0, added 0, done\n"
         }

I've spent hours trying to pin it down to something, and unfortunately, I cannot find precisely what is causing this.

But this change is the closest to all the clues I can find.

[moltar]

What is also odd, is that some PRs are fine, and some are not.

Debugging is further exacerbated by the lack of ppm error messages (see #28536).

Another clue is that it might be related to this: pnpm/pnpm#7978

Which would explain why some PRs are ok, maybe they do not have peer issues.

[rarkins]

@moltar please start a new discussion instead