Last pnpm version that worked
10
pnpm version
11
Code to reproduce the issue
Have a server that expose tarballs Content-Encoded with gzip, pnpm 11 refuse to download them
Expected behavior
❯ pnpm i
Scope: all 39 workspace projects
Progress: resolved 2150, reused 0, downloaded 1982, added 0, done
Done in 47.6s using pnpm v10.33.2
Actual behavior
❯ pnpm --version
11.0.5
❯ pnpm i
Scope: all 39 workspace projects
[WARN] GET https://artifactory.example.org/cli-cursor/-/cli-cursor-5.0.0.tgz error (ERR_PNPM_BAD_TARBALL_SIZE). Will retry in 10 seconds. 2 retries left.
[WARN] GET https://artifactory.example.org/cli-cursor/-/cli-cursor-5.0.0.tgz error (ERR_PNPM_BAD_TARBALL_SIZE). Will retry in 1 minute. 1 retries left.
... about 300 other lines of `(ERR_PNPM_BAD_TARBALL_SIZE). Will retry in <delay>. <n> retries left.` warning
/Users/me/dev/myrepo/myproject:
[ERR_PNPM_BAD_TARBALL_SIZE] Actual size (1927) of tarball (https://artifactory.example.org/cli-cursor/-/cli-cursor-5.0.0.tgz) did not match the one specified in 'Content-Length' header (1952)
This error happened while installing the dependencies of ora@9.4.0
Seems like you have internet connection issues.
Try running the same command again.
If that doesn't help, try one of the following:
- Set a bigger value for the `fetch-retries` config.
To check the current value of `fetch-retries`, run `pnpm get fetch-retries`.
To set a new value, run `pnpm set fetch-retries <number>`.
- Set `network-concurrency` to 1.
This change will slow down installation times, so it is recommended to
delete the config once the internet connection is good again: `pnpm config delete network-concurrency`
NOTE: You may also override configs via flags.
For instance, `pnpm install --fetch-retries 5 --network-concurrency 1`
Progress: resolved 2085, reused 0, downloaded 1849, added 1842command takes 8m0s to "complete"
Additional information
pnpm 11 has added a strict check between Content-Length header value and actual downloaded size. But that doesn't account for Content-Encoding particularity, as documented by mdn:
When the Content-Encoding header is present, other metadata (e.g., Content-Length) refer to the encoded form of the data, not the original resource
some possibilities:
- for already compressed tarballs, request them with
Accept-Encoding: identity which disable content encoding, the strict check can stay
- if
Content-Encoding header is present, disable the check
- use more low level undici api, like request and its decompress interceptor, this one, according to the PR, removes content-length header in the presence of content-endoding one
Node.js version
v22.22.0
Operating System
macOS
Last pnpm version that worked
10
pnpm version
11
Code to reproduce the issue
Have a server that expose tarballs Content-Encoded with gzip, pnpm 11 refuse to download them
Expected behavior
Actual behavior
command takes 8m0s to "complete"
Additional information
pnpm 11 has added a strict check between Content-Length header value and actual downloaded size. But that doesn't account for Content-Encoding particularity, as documented by mdn:
some possibilities:
Accept-Encoding: identitywhich disable content encoding, the strict check can stayContent-Encodingheader is present, disable the checkNode.js version
v22.22.0
Operating System
macOS