#20751: fix: zfs dockerfile pnpm hardlink

## Summary - **Problem:** Docker build fails on ZFS with `EAGAIN: resource temporarily unavailable` during `pnpm install` - **Root cause:** pnpm's `auto` import method detection fails on ZFS, falls back to `copy`, and `copyfile()` has issues on ZFS (pnpm/pnpm#5803 — open for over a year) - **Fix:** Force `--package-import-method=hardlink` to bypass the broken detection - **Scope:** Single-line change to Dockerfile, no runtime behavior affected ## Change Type - [x] Bug fix ## Scope - [x] CI/CD / infra ## Linked Issue - Closes #5661 - Related: pnpm/pnpm#5803 (upstream ZFS issue, unresolved) ## User-visible / Behavior Changes None. Docker builds on ZFS now succeed. ## Security Impact - New permissions/capabilities? **No** - Secrets/tokens handling changed? **No** - New/changed network calls? **No** - Command/tool execution surface changed? **No** - Data access scope changed? **No** ## Why this workaround? The upstream pnpm issue (pnpm/pnpm#5803) has been open since Oct 2023 with no fix. Multiple reports confirm the issue on: - ZFS (Linux, FreeBSD) - Docker Desktop on macOS (gRPC FUSE, VirtioFS) - Dev containers with volume mounts The `hardlink` method works on all major Linux filesystems (ext4, XFS, ZFS, btrfs, overlay2) and avoids the problematic `copyfile()` path entirely. For this Dockerfile (no BuildKit cache mounts, single-layer build), `hardlink` is safe and has no performance penalty. ## Evidence - Issue reporter confirmed fix works: [hoppscotch/hoppscotch#4960](https://github.com/hoppscotch/hoppscotch/issues/4960#issuecomment-2780903150) - Same workaround used by multiple projects facing the same issue ## Compatibility / Migration - Backward compatible? **Yes** - Config/env changes? **No** - Migration needed? **No** ## Risks and Mitigations - **Risk:** None for this Dockerfile. Hardlink works on overlay2 (Docker's default) and all common Linux filesystems. - **Note:** `hardlink` would fail if store and node_modules were on different filesystems (e.g., BuildKit cache mounts), but this Dockerfile doesn't use cache mounts. <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds `--package-import-method=hardlink` flag to `pnpm install` in the main Dockerfile to fix build failures on ZFS filesystems. The change addresses a known pnpm issue (pnpm/pnpm#5803) where pnpm's automatic filesystem detection fails on ZFS, causing `EAGAIN: resource temporarily unavailable` errors during `copyfile()` operations. By forcing hardlink mode, the Dockerfile bypasses the problematic copy method entirely. - Single-line change to Dockerfile:24 - No runtime behavior changes - Compatible with Docker's overlay2 filesystem and common Linux filesystems (ext4, XFS, btrfs, ZFS) - Note: The test in `src/dockerfile.test.ts:12` checks for the exact string `"RUN pnpm install --frozen-lockfile"` and will need updating to match the new command with the additional flag <h3>Confidence Score: 4/5</h3> - Safe to merge after fixing the test - the Dockerfile change is minimal and well-justified - The change is a minimal, well-documented workaround for a known upstream issue. The approach is validated by external reports and safe for Docker's overlay2 filesystem. However, the test in `src/dockerfile.test.ts:12` will fail because it searches for an exact string that no longer matches the updated command. Once the test is updated, this is safe to merge. - Update `src/dockerfile.test.ts` to match the new pnpm command _{Last reviewed commit: 55b511f} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->