Support rangeStrategy=update-lockfile for pnpm

[rarkins]

What would you like Renovate to be able to do?

As per above

If you have any ideas on how this should be implemented, please tell us here.

Depends on #19038

Then should add support for updateLockedDependency()

Is this a feature you are interested in implementing yourself?

No

[DavidS-ovm]

#19038 is now closed fixed, so this might be unblocked now.

As a pnpm shop, this is quite the blocker for us.

[rarkins]

PRs welcome

[pataar]

@rarkins I'd like to give it a try. Can you give a nudge in the right direction? Where can I find the yarn.lock parsing for example?

[rarkins]

Hi @pataar! Thanks for offering.

Perhaps the most important part doesn't require knowledge of Renovate code but rather of how pnpm works.

The Scenario is:

• There's a range constraint for a dependency in package.json, e.g. ^1.0.0
• The pnpm lock file resolves this to a version in-range, such as 1.2.3
• The latest version is 1.5.0, but we wish to upgrade it to 1.3.0 specifically

In this case there's usually three ways to approach it.

1. Occasionally a package manager is featureful enough that you can ask it to do this via a command-line argument, e.g. like pnpm upgrade foo 1.3.0.
2. Instead we can lightly edit the lock file and then run e.g. pnpm lock and have it update the remaining parts of the lock file (e.g. in case transitive dependencies changed).
3. We can potentially manipulate the package.json to reference 1.3.0 instead of ^1.0.0, run pnpm to update the lock file, then revert the package.json change and run it again, and.. it works

So you need to research:

• Is there any pnpm command which can let us "surgically" update a locked version? (and btw the pnpm maintainer is wonderful and might be open to adding this feature if not)
• Or, does pnpm let us mutate the lock file manually and then it "repairs" it for us (e.g. fills in sha's, changes transitive dependencies if necessary, etc)
• Or, can we do the package.json manipulation trick

[alan910127]

Hello, a random guy who hopes this feature can be realized here.

Based on my (limited) knowledge, we can either use add, install, or update with the syntax pkg@version (foo@1.3.0 for example) to upgrade a dependency to a specified version.
However, all of the above modifies the package.json, but it seems to work with the third approach mentioned above.

[pataar]

Hello, a random guy who hopes this feature can be realized here.

Based on my (limited) knowledge, we can either use add, install, or update with the syntax pkg@version (foo@1.3.0 for example) to upgrade a dependency to a specified version. However, all of the above modifies the package.json, but it seems to work with the third approach mentioned above.

What if we save the state of package.json before executing those commands, and restoring it afterwards. And simply run pnpm install to make the right corrections to the lockfile? Worth trying at least.

// edit: that's basically what @rarkins said in his approach examples

[rarkins]

Yes:

• Manipulate the package.json
• Run pnpm install
• Revert the package.json manipulation
• Run pnpm install again
• Verify it's still like we want

[alan910127]

When I left that comment a few hours ago, I literally went through the install-revert-install process to update one of my dependencies to a newer, but not latest, version. And it works just as we expected.

IMO, even though it is not a graceful solution, it is totally feasible.

[segevfiner]

I think pnpm update does essentially something similar except the revert the package.json part, not sure if it has a --no-save flag to do the change without modifying the package.json, maybe it does?

[alan910127]

@segevfiner I just tried it, and it does that! 😄

[rarkins]

Please check that pnpm update allows exact versions to be specified, otherwise it's not what we need

[alan910127]

I think this shows that it is what we need:

[rarkins]

That looks like the type of update which would change package.json, unless you had it set to a range like *. Better to pick a non-major update example to test with

[alan910127]

This should be a better example:

Edit:

package.json

[github-actions]

Hi there,

Get your discussion 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 discussion 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

[rarkins]

Someone please create a reproduction repo demonstrating a repo where:

• package.json uses a range
• there are at least 2 versions out of date

[alan910127]

Just opened a reproduction repo: renovate-reproduction-21438.

Please let me know if there is something I missed.

[rarkins]

Reproduction forked to https://github.com/renovate-reproductions/21438

[uberflip-jbooth]

I've done a bit of testing on my own repo and pnpm update "<package_name>@<version>" --no-save makes a lot more changes to pnpm-lock.yaml than pnpm add "<package_name>@<version>". The latter seems more like the expected behaviour, the only catch is reverting package.json afterwards.

[guillaumeduboc]

I've been looking into this these past days
First of all thanks for the repro example and the --no-save for pnpm !

I have a working pr #26770 but I am not completely sure about the implementation inside renovate. Especially I don't get the difference between

• updateLockedDependency in update

  renovate/lib/modules/manager/npm/update/locked-dependency/index.ts

  Line 7 in b69416c

  export async function updateLockedDependency(

• generateLockFile in post-update

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

  Line 28 in 6c2263e

  export async function generateLockFile(

[renovate-release]

🎉 This issue has been resolved in version 37.207.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀