Add .npmrc save-exact=true and pin remaining caret ranges

[nielsbosma]

Problem

The frontend project at src/frontend/ uses pnpm with a lockfile, but there is no .npmrc with save-exact=true. This means pnpm add <pkg> will default to inserting ^ (caret) ranges, allowing non-deterministic version resolution if the lockfile is deleted or regenerated.

Currently, most dependencies in package.json already use exact versions, but three devDependencies still have caret ranges:

• @types/mdast: ^4.0.4
• husky: ^9.1.7
• lint-staged: ^16.4.0

Solution

1. Create .npmrc at src/frontend/.npmrc with save-exact=true
2. Pin the 3 caret-range devDependencies in src/frontend/package.json
3. Run pnpm install to regenerate the lockfile with pinned versions

---

Plan ID: 01390

[rorychatt]

@claude review this.

I don't think we need this since

a) all non-dev packages are already strictly typed to specific versions
b) we likely won't be adding new packages, but we still want fresh improvements to dev packages for dev experiences.

[ivy-interactive-claude-code]

Claude finished @rorychatt's task in 59s —— View job

---

Review: .npmrc and Pinned Dependencies Proposal

• Gather context - read current package.json and check for existing .npmrc
• Analyze current dependency versioning state
• Provide review feedback on the proposal

---

I agree with your assessment. The proposal is more cautious than necessary. Here's my analysis:

Current State

• Production dependencies: All 84 packages use exact versions ✓
• devDependencies: 3 packages have caret ranges:
  • husky: ^9.1.7
  • lint-staged: ^16.4.0
  • @types/mdast: ^4.0.4 (also duplicated in dependencies as exact 4.0.4)

Why this change isn't needed

1. Production is already deterministic - What matters most (runtime dependencies) is already pinned. The caret ranges only affect dev tooling.

2. Lockfile provides reproducibility - pnpm-lock.yaml ensures CI and team members get identical versions. Caret ranges only come into play when explicitly running pnpm update or regenerating the lockfile.

3. Dev tool auto-updates can be beneficial - husky and lint-staged are development workflow tools. Allowing compatible updates means you get security patches and bug fixes without manual intervention.

Minor cleanup suggestion

There's a duplicate @types/mdast entry - it appears both in dependencies (exact: 4.0.4) and devDependencies (caret: ^4.0.4). The devDependencies entry could be removed since the types are already available from the production dependencies.

Recommendation: Close this issue. The current setup is reasonable and the tradeoffs favor flexibility for dev tooling over strict pinning.

---