Askr
Tooling

SSG Commands

Use ssg commands with the current published Askr packages.

  • @askrjs/askr0.0.59

How to use ssg commands

Point the CLI at the application-owned SSG configuration, use an explicit output directory, and fail the build when any registered route cannot render.

  1. Import the published @askrjs/askr entrypoint.
  2. Keep ssg commands 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.
npx askr ssg --config ./ssg.config.ts --output ./dist

# Verify the generated document and hosting fallback.
test -f ./dist/index.html
test -f ./dist/404.html

Configuration

askr ssg --config <path> --output <dir> requires both flags explicitly -- there's no default config path the way openapi has one. --config must point at a TypeScript module (a .ts extension is enforced; passing anything else is a validation error), and that module defines which routes get pre-rendered and how.

Output directory

--output <dir> is where the generated HTML tree lands, and it's also required -- the command refuses to run without it rather than defaulting to something like dist/. --workers <n|auto> optionally controls how many render workers the build uses, which is the main lever for tuning throughput on large route counts.

Document and assets

Each pre-rendered route becomes a static HTML document built through the same head/app marker composition that @askrjs/vite's server plugin uses at runtime, so SSG output and SSR output share the same document-assembly logic rather than diverging into two separate template systems.

Failure reporting

--incremental reuses a previous build's manifest instead of re-rendering every route from scratch, and --changed-key / --changed-route (both repeatable) let you mark specific invalidation keys or concrete paths as changed so only the affected routes get regenerated. --force-full overrides all of that and forces a complete rebuild even when incremental flags are present. When routes fail to render, the command collects and prints an "Errors encountered" section listing each failure rather than aborting on the first one, so a single bad route doesn't hide problems in the rest of the site.