Compatibility and Migration Notes
Compatibility and Migration Notes: published entrypoints, signatures, and the constraints around them.
Example
Align all Askr packages as one tested release set, read declaration and migration changes, then run the real delivery modes before accepting an upgrade.
npm ci
npm ls '@askrjs/*'
npm run typecheck
npm run test
npm run buildLatest-published scope
This site documents the @askrjs package set installed by its lockfile. The checked-in API and CLI snapshots are verified against those installed artifacts, while package versions stay internal rather than being rendered into guide and API pages.
Clean breaks
Askr's public API favors one vocabulary per concept rather than keeping deprecated aliases around — for example, reactive scope is `defineScope()`/`readScope()` with no legacy `useContext`-style alias shipped alongside it. When a release renames or removes an export, expect it to be gone rather than soft-deprecated, so pin versions deliberately if you can't absorb that immediately.
Package alignment
The @askrjs packages are developed and released together but versioned independently per package.json, so it's possible to end up with mismatched versions if you bump one without the others. When debugging a type or runtime mismatch, check that your installed @askrjs/askr, @askrjs/ui, @askrjs/themes, and @askrjs/server versions were all published around the same time before assuming it's a bug.
Migration checklist
Before upgrading, diff the exports on the relevant API Index pages against what your code currently imports — a missing symbol there means it moved or was removed, not that the docs are stale. Re-run your test suite with @askrjs/askr/testing's route-matching and query-mock helpers after any upgrade, since router and query-state shapes are exactly the kind of thing a minor bump can quietly change.