#93 · stacks/bunpress

Observed problem

The build throws on the first unresolvable Markdown link, so a docs set with N dead links takes N build runs to clean up: fix one, rebuild, learn the next, repeat. Each run is a full build.

Reproduction

@stacksjs/bunpress@0.2.28, Bun 1.4.3. Two dead links in two different files:

docs/guide.md   A link to [a page that is not there](./missing-one.md).
docs/other.md   Another link to [a second missing page](./missing-two.md).

First build:

error: Markdown link has no documentation source: ./missing-one.md

./missing-two.md is not mentioned. Repoint ./missing-one.md at a real page and rebuild:

error: Markdown link has no documentation source: ./missing-two.md

So the second was always there, and only becomes visible once the first is gone.

Why it is worth collecting them

This is the first run after an upgrade that is most affected. Moving an application from 0.2.14 to 0.2.22 turns a docs set that had never been link-checked into one that is checked for the first time, so the dead links are discovered in a batch rather than one at a time as they are introduced. Ours had three, in one file, and each needed its own build to find.

The same applies to any repository adopting the check, which is every repository that upgrades across #86.

What would help

Collect the failures across the render and report them together, then fail once:

3 Markdown links have no documentation source:
  docs/todo/12-api-and-agents.md:352  ./09-ci-cd.md
  docs/todo/12-api-and-agents.md:385  ./09-ci-cd.md
  docs/todo/12-api-and-agents.md:508  ./09-ci-cd.md

The per-failure context in that sketch is the subject of a separate issue; this one is only about reporting all of them in one run rather than the first.