fix(pnpm): replace corepack use with manual parse

[Cliffback]

Changes

Switches from using corepack use [email protected] to parse it manually the same way corepack does it themselves. Have been struggling with renovate not updating pnpm correctly.

This solution is based on the outline in #37772

First tries to get the integrity from datasource via getDigest, if unvavailable, trying from CLI with npm view. If still failing, then get the shasum from datasource and if that fails, get it from the CLI with npm view (got it from the first npm view command)

Falling back on shasum mimicks how corepack handles it: fix: fallback to shasum when integrity is not defined#542

The reason for the fallback is that some npm registries does not define an integrity field.

Context

Please select one of the following:

• This closes an existing Issue, Closes: Prevent install scripts from being run when using corepack use #37772
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

Please select one option and, if yes, briefly describe how AI was used (e.g., code, tests, docs) and which tool(s) you used.

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI-generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

Consulted with MS Copilot / GPT 5 to understand the original code + a getting a few suggestions for the parsing and tests, but worked through everything myself

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

The public repository:

[Cliffback]

Technically sha384 could also be a possible algo, so could either add a check for correct length for 384 as well, or change to only check lenght on sha512, which should be the most common algo.

[RahulGautamSingh]

this only return sha512, right?

[Cliffback]

AFAIK as long as using the official npm registry, only sha512 will be returned (from 2017 and onward)

However with other registries this might not be the case. Corepack's own readme mentions sha224 for yarn for example, and was the reason for assuming more than sha512.

But I guess for renovate can we assume to always use the official npm registry, and then expect only sha512?

[RahulGautamSingh]

But I guess for renovate can we assume to always use the official npm registry, and then expect only sha512?

@viceice thoughts?? I don't think npm regsitry will always be the case.

[viceice]

we can't assume that. we should throw an artifact error if there's something missing

[viceice]

we should reuse the response from npm datasource instead of calling npm CLI here.

datasource can maybe return it as digest

[Cliffback]

Is the PR title okay, or should it reflect the actual issue it fixes?
(avoiding prepare scripts #37772 / fixing the broken packageManager field #36904)?

[RahulGautamSingh]

The PR title is fine

[viceice]

see comment. we should return the integrity value via the getDigest function of the npm manager if it's not already available in the usual npm response.

[viceice]

we should reuse the response from npm datasource instead of calling npm CLI here.

datasource can maybe return it as digest

[Cliffback]

see comment. we should return the integrity value via the getDigest function of the npm manager if it's not already available in the usual npm response.

Added a couple of commits addressing this. I'm not sure if this was the way you intended, but let me know if it works or needs changing.

[Cliffback]

Should i keep the fallback on the CLI if not available in the datasource, or just remove?

[RahulGautamSingh]

I don't think we need a new funciton. The getReleases fn already gets this info (integrity & shasum) when fetching new releases for the package managers.

Can you confirm if this is still true? Cause it was the last time I checked IIRC.

[Cliffback]

@RahulGautamSingh Yeah, I checked that first, and I didn't find anything in the ReleaseResult interface that I could use, since it is not a npm-specific type.

@viceice also mentioned the getDigest function, so seemed the better choice.

I might be wrong though, so I can happily rewrite if I can get a hold on how to do it.

[RahulGautamSingh]

It's not in the ReleaseResult interface as we didn't need to track those fields previously. But, I think if you check the response you might find them.

[Cliffback]

I see. Where would i need to look then?

Tried to mock the npm request in the test file, and log out everything I get from the response from getReleases, and this is all I get:

{
  "homepage": "https://pnpm.io",
  "releases": [
    {
      "version": "8.15.6",
      "dependencies": {},
      "devDependencies": {},
      "attestation": false,
      "releaseTimestamp": "2024-01-01T00:00:00.000Z",
      "constraints": {
        "node": [
          ">=18.12"
        ]
      }
    }
  ],
  "tags": {
    "latest": "8.15.6"
  },
  "registryUrl": "https://registry.npmjs.org",
  "sourceUrl": "git+https://github.com/pnpm/pnpm.git",
  "isPrivate": true
}