Dependency Policy

Principles

ByteBite uses current stable dependency majors at bootstrap stage. This is intentional: the repository has no released product functionality yet, so now is the best time to align with current stable releases and official documentation.

• Prefer current stable majors unless there is a concrete, documented incompatibility.
• Do not run blind automated major upgrades (pnpm update -r --latest without review).
• Official documentation is authoritative for setup and migration (especially Fumadocs, Next.js, Tailwind, shadcn/ui, Drizzle, Better Auth).
• Pinned versions live in pnpm-lock.yaml; package.json ranges use ^ for patch/minor flexibility within the chosen major.
• No beta, alpha, rc, canary, or experimental releases unless explicitly required and documented.

Runtime baseline

Upgrade process

1. Inventory direct dependencies across all workspace package.json files.
2. Check latest stable version via registry (pnpm view <pkg> version).
3. Read official migration notes for major upgrades.
4. Upgrade deliberately, one area at a time if needed.
5. Run the full validation suite: pnpm install --frozen-lockfile, format, lint, typecheck, test, build, Docker stack.
6. Document any deliberate version exceptions with reason and revisit date.

Dependency versions are implementation details

Package versions are not recorded in ADRs unless a major version represents an architectural constraint (e.g. "we use PostgreSQL" is architectural; "we use drizzle-orm 0.45" is not).

Security

Run pnpm audit periodically. Fix straightforward issues caused by stale versions. Do not apply force fixes without understanding reachability.