Skip to content

Docs: Website.Astro output default contradicts the astro-static fixture; Better Auth tutorial link 404s #1765

Description

@Floriferous

Two small documentation problems found while setting up a starter on 2.0.0-beta.79. Happy to open a PR for either if you'd prefer.

1. Website.Astro's astro.output default contradicts the fixtures

AstroProps.astro.output is documented as:

Astro output target … "static" prerenders every page at build time and deploys assets-only. Supersedes a file-level output.
@default "server"

Read literally, an existing fully-static Astro site becomes SSR on its first Alchemy deploy unless astro: { output: 'static' } is passed, because the prop's default supersedes the config file.

But packages/frontend-frameworks/fixtures/astro-static asserts the opposite, emphatically:

A REAL user config file declaring a fully-static site. The integration must honor it (the user-config principle) AND respect what it implies: output: "static" means every route is prerendered at build time, so the production artifact is ASSETS-ONLY.

Both cannot be true. Which wins decides whether a static site silently gains a Worker, so it would help to state it explicitly — presumably "the file wins; this prop is an override for when it must be computed", with @default reworded since an unset override has no default.

I passed it explicitly to avoid depending on the answer.

2. Dead link to the Better Auth tutorial

examples/cloudflare-better-auth/README.md links to a six-part tutorial at https://alchemy.run/better-auth/tutorial/part-1, which 404s (as do the sibling parts). The example itself is excellent and was what I worked from — @alchemy.run/better-auth's auth.fetch / auth.getSession() plus the HttpApiMiddleware pattern is not obvious from the API docs alone, so if that tutorial exists in draft it is worth publishing, and if not, worth unlinking.

Also, minor

The pnpm CI recipe in the docs uses pnpm dlx alchemy deploy, which resolves alchemy from the registry rather than the version in the lockfile. For a repo that pins alchemy and every @alchemy.run/* package to an exact version — necessary, since they are version-locked to each other — pnpm exec seems safer. Possibly deliberate to avoid an install step, in which case ignore this.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions