Askr
Tooling

Dependency Updates

Use dependency updates with the current published Askr packages.

  • @askrjs/askr0.0.59

How to use dependency updates

Inspect updates first, apply safe peer-compatible changes separately, and run the full application build before accepting an upgrade.

  1. Import the published @askrjs/askr entrypoint.
  2. Keep dependency updates configuration next to the component, route, or server composition root that owns it.
  3. Handle pending, unavailable, cancellation, and failure states, then verify the production path.
askr outdated
askr update
npm run check

# Use only when you intend the latest peer-compatible set:
askr upgrade

outdated

askr outdated [packages...] [--workspace <glob>] [--tag <tag>] [--json] is purely read-only: it discovers the containing npm or pnpm workspace (including the root manifest and any declared workspace packages), checks each dependency against the registry, and reports results without writing anything. Pass specific package names or globs to narrow the check, --workspace to limit which workspace packages are considered, and --json for machine-readable output suited to scripting.

update

askr update applies only safe version-range changes -- bumps that stay within a dependency's already-declared range style. It preserves whichever range style a dependency was already pinned with (exact, caret, tilde, or x-range), can widen one bounded interval, and updates only the highest clause of a simple OR union; anything more complex than that is reported as manual rather than guessed at.

upgrade

askr upgrade does everything update does, plus it permits next-version major bumps for stable (1.0+) packages and breaking minor bumps for 0.x packages, since semver treats 0.x minor bumps as potentially breaking. It still enforces peer compatibility across your selected packages -- a target that would land outside another package's declared peer range is left for manual review instead of being forced through, and upgrade never bypasses that guard.

Review and rollback

All three commands classify every dependency into one of five buckets -- safe, breaking, local, manual, or failed -- and print that breakdown so you can see exactly what would move before anything writes. Because update and upgrade only ever change version strings in package.json (never a lockfile, never overrides/resolutions/catalogs/packageManager, never an install or lifecycle script), rolling back a run that went wrong is just git checkout -- package.json with no lockfile or node_modules cleanup required.