If we introduce version 3, current packages that use the non-existent
version 3 will get their hashes broken. Prevent stupid LLMs from
introducing more trouble when hallucinating more non-existent versions.
With fetcherVersion = 1 and 2 removed, the minimum supported version is 3,
so every store is a reproducible tarball with consistent permissions. Drop
the now-unreachable `fetcherVersion < 3` branches:
- always bundle the store into pnpm-store.tar.zst (drop the direct-to-$out path)
- always write $out/.fetcher-version (drop the `> 1` guard)
- always normalise permissions (drop the `>= 2` guard)
- always extract the tarball in pnpmConfigHook and serve.nix (drop the cp
fallback and the `|| echo 1` default)
The `>= 4` SQLite-dump guard is kept, since v3 and v4 still differ. Output
for existing v3/v4 derivations is byte-identical, so no hashes change.
Assisted-by: claude-code with claude-opus-4-7[1m]-xhigh
fetcherVersion = 1 and 2 were deprecated in the 26.05 release and
scheduled for removal in 26.11. Remove them from supportedFetcherVersions
and replace the deprecation warning with a hard throw that points users
at the migration to fetcherVersion = 3.
No in-tree package still uses fetcherVersion = 1 or 2. The now-unreachable
v1/v2 code paths are removed in a follow-up commit.
Assisted-by: claude-code with claude-opus-4-7[1m]-xhigh
The deprecated singular `pnpmWorkspace` attribute (superseded by
`pnpmWorkspaces` in #350751) has no remaining in-tree users, so the
assert and hook check pointing users to the new attribute are no
longer needed.
Assisted-by: Claude Code (Claude Opus 4.7)
This should help debugging config values. I verified that `pnpm config
list` works across pnpm_8, pnpm_9, pnpm_10, pnpm_10_29_2 and pnpm_11.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
These checks are still performed in fetchPnpmDeps. These checks require
access to the registries used in the lockfile, making it infeasible to
run during configurePhase in a sandboxed build.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
The pnpm v11 store uses a SQLite database (index.db) whose binary format
is non-deterministic across platforms (version-valid-for number, etc).
This caused hash mismatches when building the same pnpmDeps on different
machines despite identical logical content.
Fix by dumping the SQLite database to a text SQL file during the fetch
phase and reconstructing it during the build phase. This ensures the
stored representation is fully deterministic.
Assisted-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Gergő Gutyina <gutyina.gergo.2@gmail.com>
pnpm 11 does not support configuring some options through its new global
config format. As a workaround, we can define these environment
variables instead.
This also adds support for the new pmOnFail option in pnpm 11 that
replaces managePackageManagerVersions.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
Extend the existing v1 deprecation warning to also fire for
`fetcherVersion = 2`, since callers should migrate directly to
`fetcherVersion = 3`. Both pre-v3 versions now share a single
`lib.warnIf` keyed on `fetcherVersion < 3` and produce a message
parameterised by the offending version.
Consolidate the manual's version-history entries: the per-item
**Deprecated** and **Recommended** labels are replaced by a single
sentence above the list noting that v3 is recommended and v1/v2 are
scheduled for removal.
Add a release note mirroring the existing v1 entry.
If the lockfile is empty, no files will be put in the output directory.
In this case, the find invocations produce an empty list of results.
xargs' default behaviour is to always invoke its command at least once;
if its input is empty, then its command will not be passed any
filenames. This produces an invocation like `chmod 555`. chmod, however,
fails in this case, expecting an operand. So we need to tell xargs not
to invoke its command at all in the case of empty input.
fetcherVersion = 1 was kept around for backwards compatibility while
callers migrated to 2/3.
Emit a `lib.warnIf` warning pointing at the affected pname whenever v1
is used.
After 26.11 ships, a follow-up PR should drop 1 from
`supportedFetcherVersions` and clean up the dead v1 code paths in
default.nix, pnpm-config-hook.sh and serve.nix.
Also rewrite the manual section to recommend fetcherVersion = 3 for new
packages and mark v1 as deprecated/scheduled-for-removal in the
version history.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
