Explicitly ignore ERR_PNPM_ERR_PNPM_TARBALL_INTEGRITY

[SebastienGllmt]

Contribution

• I'd be willing to implement this feature (contributing guide)

Describe the user story

Using a tool like Verdaccio to manage packages locally helps a lot for local testing. My flow often looks like this:

1. Make some changes to project A
2. Publish a local-only version of project A to a local registry using Verdaccio
3. Update project B to use the new version of A published in step (2)

and I iterate on this loop until things compile and the code feels good.

Note: I do NOT want to have to bump the version of A every single time I iterate. It gets messy, causes conflicts if I push my branch, and in general it's a lot of busy work

However, if I keep the exact same version number, I get  ERR_PNPM_TARBALL_INTEGRITY  which causes pnpm install to take a minute to install everything as it has to exhaust the retry count

 WARN  GET http://localhost:4873/package-A.tgz error (ERR_PNPM_TARBALL_INTEGRITY). Will retry in 10 seconds. 2 retries left.

 WARN  GET http://localhost:4873/package-A.tgz error (ERR_PNPM_TARBALL_INTEGRITY). Will retry in 1 minute. 1 retries left.

 WARN  Got unexpected checksum for "http://localhost:4873/package-A.tgz". Wanted "sha512-...". Got "sha512-...".

 ERR_PNPM_TARBALL_INTEGRITY  The lockfile is broken! A full installation will be performed in an attempt to fix it

Describe the solution you'd like

I want an option to just force the installation of the new package even if the sha512 differs without having to wait for all the retries

I tried --fix-lock and --force, and neither of them seem to give me what I want

Describe the drawbacks of your solution

This option could hide a case where a package actually differs in its hash due to a bug, although unlikely

Describe alternatives you've considered

https://github.com/orgs/verdaccio/discussions/4866

[KSXGitHub]

I wonder if this works for you:

If you use a registry that allows to override existing versions of a package, then it might mean that in your local metadata cache you have the integrity checksum of an older version of the package. In this case, you should run pnpm store prune. This command will remove your local metadata cache. Then you can retry the command that failed.

-- taken from https://pnpm.io/errors#err_pnpm_tarball_integrity

[SebastienGllmt]

I've tried the following steps:

1. remove all instances of the packages I want to update from my repo
2. run pnpm install to update the fact these packages are removed
3. remove my node_modules directory to clear out any remaining traces of the package
4. run pnpm store prune to remove any global cache entry

and then if I try and add them back, it works properly. This isn't a productive workaround though since it takes some amount of time to manually delete all trace of these packages only to just re-add them again

[KSXGitHub]

remove my node_modules directory to clear out any remaining traces of the package

Is this step necessary? Can you also omit this?

Is pnpm store prune && pnpm install enough?

[zkochan]

Why do you need to publish to verdaccio? You can install from a local tarball. I used something like that in the past and created this tool: https://github.com/zkochan/package-preview

[SebastienGllmt]

@KSXGitHub Is pnpm store prune && pnpm install enough?

No, it's not enough. This will still result in a ERR_PNPM_TARBALL_INTEGRITY error. In fact, it's even worse than not enough - it actually doesn't even install the latest version of your package at all if you do just this instead of fully clearing the cache

Why do you need to publish to verdaccio? You can install from a local tarball. I used something like that in the past and created this tool

I'm using Verdaccio precisely to avoid having to use hacky tools like package-preview which I think fundamentally will never work as well as something like Verdaccio

[EdivenH]

How did you solve it? I also encountered this problem.

[zkochan]

Why do you need to publish to verdaccio? You can install from a local tarball. I used something like that in the past and created this tool

I'm using Verdaccio precisely to avoid having to use hacky tools like package-preview which I think fundamentally will never work as well as something like Verdaccio

I don't care if you use package-preview. How is installing from a local tarball different than installing from verdaccio? It will produce the same result.

I am not sure disabling this check in pnpm is a good idea even as an opt-in. It will be a security vulnerability. Providing a list of packages for which to ignore the check could be safer but I am not sure this is a frequent enough use case.

You could just publish your packages with hashes, when you do local testing. Like 0.0.0-hash1, then 0.0.0-hash2. In that case you won't have the issue. Also, this way you will never accidentally publish a test package with a normal version to the public registry.

Note: I do NOT want to have to bump the version of A every single time I iterate. It gets messy, causes conflicts if I push my branch, and in general it's a lot of busy work

What is the issue with bumping versions? Do you commit the lockfile created by e2e tests? Looks like you need to improve the automation. Maybe use a release tool that will bump the versions automatically.

[Wxh16144]

I also encountered the same problem, feeling terrible. I also used Verdaccio.

[Armadillidiid]

Ran into this as well. I had a bug fix in a fork that I needed immediately, so I vendored the package as a local tarball via pnpm overrides.

The lockfile ends up storing the checksum from the npm registry rather than recomputing it from the local tarball, causing ERR_PNPM_TARBALL_INTEGRITY on every install.

I really don't want to add verify-store-integrity=false. That's just not ideal.