fix(nix): pin pnpm bits to flake's own nixpkgs #99
No reviewers
Labels
No labels
app:activities
app:chat
app:events
app:forum
app:libra
app:market
app:restaurant
app:tasks
app:wallet
app:webapp
bug
enhancement
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
aiolabs/webapp!99
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/flake-pnpm-from-flake-nixpkgs"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes the deploy-time
ERR_PNPM_NO_OFFLINE_TARBALL @vite-pwa/assets-generator-1.0.2.tgzregression introduced by #98.Root cause
mkWebappwas sourcingpnpm,fetchPnpmDeps,pnpmConfigHookfrom the consumer'spkgs.fetchPnpmDepsproduces a snapshot whose byte content depends on the exact pnpm version running it — even minor 10.33 → 10.34 differences produce mismatched snapshots. The pinned hash matches one snapshot exactly, so any consumer with a different nixpkgs (server-deploy, in this case) hits a tarball that isn't in the snapshot.My #98 commit message claimed pinning
pkgs.pnpm_10"still allowing minor drift inside major-10" was fine. That was wrong — minor drift breaks snapshot reproducibility.Fix
mkWebappnow derives aflakePkgsfrom this flake's own pinned nixpkgs (taking only thesystemattribute from the consumer'spkgs), and sourcespnpm,pnpmConfigHook,fetchPnpmDeps,nodejs,autoPatchelfHook,stdenv, andstdc++from it.Consumer's
pkgsis essentially unused except for its system. The build is now reproducible regardless of which nixpkgs is calling.The pinned
pnpmDepshash (sha256-FUN2lMHsaBTkk1tljDysYZAoQD+5MIBIEvGnRUWiF4s=) is unchanged — it was always computed against the flake's own nixpkgs, so it stays valid.Test plan
nix build .#main— works, produces dist/ with 6 iconsnix build --impure --expr '...lib.mkWebapp { pkgs = <system>; brandDir = /tmp/fixture; app = "events"; }'— now succeeds where it would previously hitERR_PNPM_NO_OFFLINE_TARBALL; fixture's "Sortir" branding propagates end-to-endFollow-up
Worth documenting in
branding/README.mdthat the consumer'spkgsargument is mostly cosmetic. The API stays the same so server-deploy'sinputs.webapp.lib.mkWebapp { inherit pkgs; brandDir = ./../branding; }keeps working —pkgsjust contributes the system selector now.🤖 Generated with Claude Code
mkWebapp was passing the consumer's `pkgs.pnpm_10` into fetchPnpmDeps, which means the pnpmDeps snapshot is byte-for-byte different across consumers using different nixpkgs minor versions (flake's nixos-unstable has pnpm_10@10.34.0, server-deploy's nixpkgs may have a different 10.x). The pinned hash matches one snapshot exactly, so the wrong consumer gets: ERR_PNPM_NO_OFFLINE_TARBALL @vite-pwa/assets-generator-1.0.2.tgz at deploy time. Fix: derive a `flakePkgs` from THIS flake's pinned nixpkgs (via `flakePkgsFor`) and source pnpm, pnpmConfigHook, fetchPnpmDeps, nodejs, autoPatchelfHook, stdenv, and stdc++ from it. The consumer's `pkgs` argument is now used only for its system attribute. Net effect: the pnpmDeps snapshot is now reproducible regardless of who's calling mkWebapp. The pinned hash sha256-FUN2lMHsaBTkk1tljDysYZAoQD+5MIBIEvGnRUWiF4s= remains valid (it was computed against the flake's own nixpkgs originally). Verified: - `nix build .#main` — produces same dist/ as before (uses flake pkgs internally either way) - `nix build --impure --expr '...lib.mkWebapp { pkgs = <system>; ... }'` — now succeeds with the system's nixpkgs, where it would fail before with NO_OFFLINE_TARBALL on @vite-pwa/assets-generator Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>