Changelog

Repository history on a page, generated from the git log at build time.

<fd-changelog> lists the repository's commits, newest first and grouped by month. The data comes from git log during npm run docs:build, so there is no changelog file to keep up to date — write good commit messages and the page writes itself.

Commit subjects that follow the Conventional Commits convention (feat:, fix:, docs: …) get a badge and lose the prefix from the headline. Anything else is shown verbatim. Each hash links to the commit on GitHub when github.repo is configured.

Example 

<fd-changelog limit="5"></fd-changelog>

Renders as:

Attributes

Maximum number of commits to show. 0 shows every commit the build collected. Only commits that touched a file under the docs folder — content changes without the framework noise. Present-as-attribute means true. Another repository, as owner/name. It must be listed in changelog.repos. Unset means this repository.

Other repositories

One docs site often covers several products, each with its own repository. List them in changelog.repos — GitHub and Azure DevOps are both supported:

// feastdocs.config.mjs
changelog: {
  limit: 150,
  repos: [
    'acme/checkout-api',
    { repo: 'acme/mobile-app', branch: 'release' },
    { provider: 'azure', org: 'contoso', project: 'Payments', repo: 'payments-api', id: 'payments' },
  ],
},

Then point a page at one:

<fd-changelog repo="acme/checkout-api" limit="30"></fd-changelog>
<fd-changelog repo="payments"></fd-changelog>

Commit links follow the source, so Azure entries link to Azure DevOps. A repository that is not in changelog.repos renders a notice naming it, rather than an empty page.

Full walk-through, including tokens per host and how to read the build log: changelogs for several products.

Private repositories

They work the same way, with a token in the build environment — see the manual for each host:

A fine-grained personal access token with Contents: Read-only on the repositories you list, or a classic token with the repo scope.

Cloudflare Pages → Settings → Environment variables, as an encrypted variable named GITHUB_TOKEN (GH_TOKEN also works). On GitHub Actions, a repository secret passed as env:. Never put it in feastdocs.config.mjs — that file is committed.

The token is read at build time only. It is not shipped to the browser and does not appear in the generated bundle.

Private history becomes public

The commits are baked into the deployed page. Everything collected — subjects, bodies and author names — is readable by anyone who can open the site, even though the repository itself stays private. Only list private repositories whose commit messages you would publish.

Setting a token is worth it for public repositories too: anonymous GitHub API calls are limited to 60 per hour per IP, shared with every other build on the same host.

How much history

The build reads changelog.limit commits (default 150) — see configuration. The history lands in its own generated module and is imported lazily, so pages without the component never download it.

Shallow checkouts are handled for you

The changelog needs real history, and several hosts clone with --depth 1 — Cloudflare Pages does, and so does any CI step missing fetch-depth: 0. That would leave a one-entry changelog and blank author attribution.

The build handles it: it deepens a shallow checkout (git fetch --unshallow) before reading anything. If deepening is impossible — no credentials in the checkout, or an offline build — it reads the history from the GitHub API instead, using github.repo and github.branch. Set GITHUB_TOKEN in the build environment if the repository is private.

The API path carries no file list, so entries show no file count and the docs-only view keeps everything it cannot rule out. Setting fetch-depth: 0 in your own pipeline still gives the best result, and the bundled workflows do.