Reference
Use reference with the current published Askr packages.
@askrjs/askr0.0.59
How to use reference
Import only the entrypoint that owns the API. Use generated reference pages for exact signatures and this guide for behavioral constraints.
- Import the published @askrjs/askr entrypoint.
- Keep reference configuration next to the component, route, or server composition root that owns it.
- Handle pending, unavailable, cancellation, and failure states, then verify the production path.
import * as api from '@askrjs/askr';
// Stay on the published entrypoint instead of reaching into dist/ or src/.
const availableExports = Object.keys(api);API index
Every published Askr entrypoint has a generated reference page under /docs/reference/api, built straight from the declaration files each package ships in dist/. There's no hand-maintained prose here — the exports, their signatures, and their JSDoc comments come from the actual .d.ts output, so the page can't drift from what you actually get when you `import` something.
Packages
The Package Map page groups every @askrjs/* package by what it's for: runtime, server, UI, and tooling. Each package has its own version and its own subpath exports (check package.json's "exports" field before assuming a subpath exists), so treat this section as the starting point when you're not sure which package a given API lives in.
Behavioral contracts
Beyond types, a few runtime behaviors are worth documenting on their own: how rendering commits, how cancellation propagates through AbortSignal, and how component instances get torn down. These aren't enforced by the type checker, so this page exists to spell out what actually happens at runtime.
Compatibility
Askr's packages are versioned independently and published together as a matched set. The compatibility page tracks which versions are meant to run together, what changed in recent releases, and what to check when you bump one package without the others.