Skip to content

v1.2.0 — the apps report their own errors

Choose a tag to compare

@climaa climaa released this 28 Aug 14:00
· 29 commits to main since this release
69da5be

Ten PRs since v1.1.0 (#394#407), telling one story: both apps went from swallowing production errors to reporting them.

What earns the minor

Layer PRs
The error boundaries neither app had #400
@gate/logger — silent in production, error() always forwards to a pluggable reporter #402
The boundaries become its first call sites #405
The Bugsink adapter behind @gate/logger/bugsink #406
Page views on the production deployment only #394, #397, #398
The 404 a streamed cache miss cannot set #399
next-env.d.ts untracked #401
The written half — the post, plus Error Tracking / Logging / Web Analytics #407

The tracker is live, not dormant: the DSN lives in Vercel's project settings, and .env.example ships both variables empty on purpose, so local runs, CI and the sandbox stay indifferent to the wiring. The story is written up in The research said GlitchTip. The decision was Bugsink., with the runbook in Error Tracking.

Nine manifests, not eight

packages/logger is new this cycle. The reason for lockstep is the one 1.0.0 stated: nothing publishes to npm, every workspace is private, so the version is a coherence marker rather than a distribution fact. Every internal dependency is workspace:*, so pnpm-lock.yaml is unaffected and --frozen-lockfile still resolves.

The one code change: .fallow/churn.bin untracked

Cutting the tag is what made the case for it. It is fallow's churn cache, rewritten as a side effect of fallow health — which is pnpm health:check, one of the eight required gate jobs. The tracked copy was therefore dirtied by every local gate run and by every agent that ran the gate before staging, and it entered the history as a side effect of PRs about something else. Two of those raced in #405/#406: the first merged, the second went CONFLICTING with auto-merge armed and stranded after the orchestrator had exited, and a binary conflict needs a human.

Nothing reads the committed copy — every run regenerates it from git history — so, exactly as with next-env.d.ts in #401, there was no correct value to commit.

The index, measured rather than adjusted

Claim Corrected to
apps/blog 18 / 359 18 / 371 (3 skipped, one per draft post)
apps/visual-diff-ui 53 / 825 53 / 829
apps/storybook 5 / 121 5 / 125
42 acceptance scenarios 44
a one-scenario local lane 2
Storybook 16 docs pages 18

EXPECTED_SCENARIOS and EXPECTED_LOCAL_SCENARIOS already said 44 and 2 — the same drift as last release, so both lines now name the constant that has to agree.

Full changelog: v1.1.0...v1.2.0