amplify.yml

# AWS Amplify Hosting — how to build the documentation site from this repository.
#
# **This file configures a build, not an account.** No credentials, no region, no
# stack, nothing environment-specific: connecting the repository to an Amplify app
# is a one-time action in the console, and everything it needs to know about *this*
# repository is here.
#
# ## The monorepo form
#
# Amplify reads `amplify.yml` from the root of the branch it builds, so the file is
# here; the app it builds is rooted at `docs/`, which is what `appRoot` says. With the
# app connected as a monorepo app whose root is `docs` (the console sets
# `AMPLIFY_MONOREPO_APP_ROOT=docs`, which must equal `appRoot`), a push that changes
# nothing under `docs/` does not rebuild the site. That is why the documentation and
# its renderer share one directory.
#
# ## What it produces
#
# Static files. `docs/astro.config.mjs` leaves `output` at Astro's default, so `pnpm
# build` writes plain HTML, CSS and JS to `docs/dist/` — no SSR, no adapter, no
# runtime. If that ever changes, this file changes with it, and so does the argument
# for using a static host at all.
#
# Building it by hand, which is all Amplify does below (commands run from `docs/`):
#
#     corepack enable
#     pnpm install --frozen-lockfile
#     pnpm build                          # → docs/dist/
version: 1
applications:
  - appRoot: docs
    frontend:
      phases:
        preBuild:
          commands:
            # pnpm from corepack, pinned by the root package.json's `packageManager`
            # field — the same source `docker/app.Dockerfile` and
            # `docker/docs.Dockerfile` read, so no build of this repository can end up
            # on a pnpm version nobody chose. One directory up, because commands run
            # from `appRoot`.
            - corepack enable
            - corepack prepare --activate "$(node -p "require('../package.json').packageManager")"
            # `--frozen-lockfile`, so a deployment installs what the lockfile names or
            # fails. A hosted build that silently re-resolves is one nobody reviewed,
            # and it is exactly what the three-day cool-down exists to prevent.
            - pnpm install --frozen-lockfile
        build:
          commands:
            # The projection of `content/` into the content collection happens inside
            # this command, in the `docsSource()` integration — so there is no separate
            # sync step to forget, and a deployment cannot ship a stale copy.
            - pnpm build
      artifacts:
        baseDirectory: dist
        files:
          - "**/*"
      cache:
        paths:
          # pnpm's store, keyed by the lockfile Amplify hashes for us. Not
          # `node_modules/`: pnpm's is a tree of symlinks into that store, and caching
          # the links without the store is how a build fails on a module that is
          # plainly installed.
          - node_modules/.pnpm/**/*