Pin package versions for better reliability and predictability

[yamcodes]

Context

Following the recommendations from Renovate's dependency pinning guide, we should consider pinning our package versions instead of using SemVer ranges for better reliability and predictability.

Current State

Currently, our package.json files use a mix of SemVer ranges (e.g., ^0.7.0, ^2.1.22) and pinned versions. This can lead to:

• Unpredictable builds when new versions are released
• Difficulty tracking which dependency version caused a breakage
• Less visibility into what versions are actually being used

Recommendations

From the Renovate documentation, here are their recommendations:

So what's best?

We recommend:

1. Any apps (web or Node.js) that aren't require()'d by other packages should pin all types of dependencies for greatest reliability/predictability
2. Browser or dual browser/node.js libraries that are consumed/required()'d by others should keep using SemVer ranges for dependencies but can use pinned dependencies for devDependencies
3. Node.js-only libraries can consider pinning all dependencies, because application size/duplicate dependencies are not as much a concern in Node.js compared to the browser. Of course, don't do that if your library is a micro one likely to be consumed in disk-sensitive environments
4. Use a lock file

As noted earlier, when you pin dependencies then you will see an increase in the raw volume of dependency updates, compared to if you use ranges. If/when this starts bothering you, add Renovate rules to reduce the volume, such as scheduling updates, grouping them, or automerging "safe" ones.

Project Structure Analysis

Based on our monorepo structure:

• Apps (should pin all dependencies):

  • apps/www - Next.js application
  • apps/playgrounds/* - Playground applications
  • examples/* - Example projects

• Libraries:

  • packages/arkenv - Node.js-only library (can pin all dependencies)
  • packages/vite-plugin - Browser/node.js library consumed by others (keep SemVer ranges for dependencies, pin devDependencies)

Benefits

• Certainty: Know exactly which version of each dependency is installed
• Visibility: See exactly what failed when upgrading versions
• Easier rollback: Can easily revert specific dependency upgrades
• Better control: Explicit PRs for each dependency update via Renovate

Considerations

• We already have a lock file (pnpm-lock.yaml) which complements pinning
• We have Renovate configured with grouping rules, which will help manage the increased volume of dependency updates
• Our Renovate schedule (weekly on Fridays) will help reduce noise

Action Items

• Pin all dependencies in apps/www
• Pin all dependencies in apps/playgrounds/*
• Pin all dependencies in examples/*
• Pin all dependencies in packages/arkenv (Node.js-only library)
• Pin devDependencies in packages/vite-plugin (keep SemVer ranges for dependencies)
• Update Renovate configuration if needed to handle increased update volume

References

• Renovate: Should you Pin your JavaScript Dependencies?