Askr
Reference

API Index

Use api index with the current published Askr packages.

  • @askrjs/askr0.0.59

How to use api index

Import only the entrypoint that owns the API. Use generated reference pages for exact signatures and this guide for behavioral constraints.

  1. Import the published @askrjs/askr entrypoint.
  2. Keep api index 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.
import * as api from '@askrjs/askr';

// Stay on the published entrypoint instead of reaching into dist/ or src/.
const availableExports = Object.keys(api);

Packages and entrypoints

Each generated API page corresponds to one subpath export — for example @askrjs/askr, @askrjs/askr/router, @askrjs/askr/testing, or @askrjs/askr/fx. The manifest that drives these pages is produced by walking package.json's "exports" map for every published @askrjs package, so a page only exists if the subpath is actually importable.

Symbols and anchors

Every exported function, class, interface, and type alias gets its own anchor on the page, named after the symbol as it appears in the .d.ts output. Linking directly to `#createRuntime` or `#state` from elsewhere in the docs is safe and stable across releases as long as the symbol keeps its name.

Type-only exports

Some exports are types with no runtime value — things like `StateTuple<T>`, `Scope<T>`, or `RouteContext<TParams>`. These show up on the API page alongside functions and classes, marked as type-only so you know not to expect them at `import` time in a value position.

Snapshot policy

The API pages are regenerated from a snapshot of each package's compiled declarations, checked in and refreshed on release. If a symbol is missing from a page, it means it isn't part of that package's public exports yet — grep the source under dist/ rather than assuming the docs are simply behind.