chore: cache node_modules in CI jobs

[43081j]

Possibly not dominik-friendly but we shall see.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Feb 5, 2026 3:06pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Feb 5, 2026 3:06pm
npmx-lunaria	Ignored		Feb 5, 2026 3:06pm

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[coderabbitai]

📝 Walkthrough

Walkthrough

The workflow adds caching steps using actions/cache@v4 to the lint, types, unit, test, browser, a11y and knip jobs, caching the node_modules directory with keys based on runner OS, architecture and the pnpm-lock.yaml hash. Cache steps are placed after the pnpm/action-setup step (and after root-level install where present). The root install command was changed from pnpm install --filter . --ignore-scripts to pnpm install --ignore-scripts.

🚥 Pre-merge checks | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The pull request description is vague and non-descriptive, using cryptic language that does not clearly convey the changeset's purpose or objectives.	Provide a clear, descriptive pull request description that explains the caching changes, their benefits, and any relevant context about potential impacts on CI workflows.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch jg/super-caches

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (2)

.github/workflows/ci.yml (2)

39-42: Missing restore-keys fallback.

Without restore-keys, any change to pnpm-lock.yaml results in a complete cache miss with no partial restoration. Consider adding a fallback key to restore an older cache that can then be updated incrementally.

Proposed fix to add restore-keys

       - uses: actions/cache@5a3ec84eff668545956fd18022155c47e93e2684 # v4
         with:
           path: node_modules
-          key: node-modules-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('pnpm-lock.yaml') }}
+          key: node-modules-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('pnpm-lock.yaml') }}
+          restore-keys: |
+            node-modules-${{ runner.os }}-${{ runner.arch }}-

---

39-42: Consider extracting repeated caching logic into a composite action.

The identical cache configuration is duplicated across 7 jobs. If the caching strategy changes (e.g., adding restore-keys or adjusting the key), all instances must be updated.

Consider creating a composite action or reusable workflow to centralise this logic, improving maintainability.

Also applies to: 66-69, 93-96, 126-129, 169-172, 202-205, 235-238

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

pnpm GitHub Actions cache setup best practices node_modules

💡 Result:

Best practices (pnpm + GitHub Actions caching)

1. Cache the pnpm store, not node_modules. actions/setup-node explicitly does not cache node_modules; it caches package-manager data (for pnpm: the store) instead. [1]
2. Use built-in caching (actions/setup-node) whenever possible: set cache: 'pnpm' so you don’t have to hand-roll actions/cache keys/paths. [1][2]
3. For monorepos / non-root lockfiles, set cache-dependency-path to the correct pnpm-lock.yaml location(s), otherwise the cache key may not reflect the right dependency graph. [1]
4. Pin pnpm via packageManager (or explicit action version) to keep installs reproducible across runners/over time (e.g., pnpm/action-setup@v4 + version: 10, or rely on packageManager in package.json). [3]
5. If you use pnpm/action-setup caching instead, enable its store caching (cache: true) and (for monorepos) point it at the right lockfile(s) via cache_dependency_path. [3]

---

Recommended workflow snippet (most common / simplest)

steps:
  - uses: actions/checkout@v4

  - uses: pnpm/action-setup@v4
    with:
      version: 10

  - uses: actions/setup-node@v6
    with:
      node-version: 20
      cache: pnpm
      # monorepo example:
      # cache-dependency-path: |
      #   pnpm-lock.yaml
      #   packages/*/pnpm-lock.yaml

  - run: pnpm install --frozen-lockfile
  - run: pnpm test

Sources: actions/setup-node caching behavior + cache-dependency-path + “does not cache node_modules” [1]; pnpm’s GitHub Actions example using cache: "pnpm" [2]; pnpm/action-setup cache inputs (cache, cache_dependency_path) [3].

References

[1] https://github.com/actions/setup-node
[2] https://pnpm.io/next/continuous-integration
[3] https://github.com/pnpm/action-setup

---

🏁 Script executed:

# Find and examine the full CI workflow file to understand the context
fd "ci.yml" --type f

Repository: npmx-dev/npmx.dev

Length of output: 43

---

🏁 Script executed:

# Now let's examine the actual workflow file
cat -n .github/workflows/ci.yml | head -50

Repository: npmx-dev/npmx.dev

Length of output: 1635

---

🏁 Script executed:

# Also check if there are pnpm/action-setup references
rg "pnpm/action-setup" .github/workflows/ci.yml -A 2 -B 2

Repository: npmx-dev/npmx.dev

Length of output: 1415

---

Remove the manual actions/cache step for node_modules.

The pnpm/action-setup with cache: true (line 37) already caches the pnpm store, making the separate node_modules cache (lines 39–42) redundant and potentially problematic. According to pnpm's official guidance, node_modules should not be cached directly because it contains symlinks to the pnpm store. Caching both separately creates a risk of broken symlinks if the cache restoration order or state becomes inconsistent.

The recommended approach is to rely solely on the pnpm store cache provided by pnpm/action-setup with cache: true. Remove the actions/cache step entirely.

Alternatively, consider using actions/setup-node with cache: 'pnpm' instead, which provides built-in, first-class support for pnpm caching and automatically includes the Node.js version in the cache key to prevent native module compatibility issues.

[43081j]

closing this as it conflicts with pnpm cache. ill find another way to speed things up 👍