Dependency Updates

askr update applies peer-compatible changes; askr upgrade moves to the latest peer set as a deliberate step.

Example

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

askr outdated
askr update
npm run check

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

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 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. The target is whatever version the registry tag currently resolves to, not the next major in sequence — there's no per-run cap limiting you to one major version at a time, so a stable package several majors behind latest can jump straight there in one upgrade. By default it enforces peer compatibility across selected packages and leaves incompatible targets for manual review. Pass --force/-f only when you intentionally want tag targets without peer compatibility checks, then install and validate the resulting package set yourself.

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.