perf(forgebook): scan a first start's dependencies quickly, carefully on failure - #213

What and why

Cold start and sidebarReady grew on every real system since 4f80455 (bench Mac: Aksel +13% cold, +30% sidebar; Fluent +29% sidebar; Salt +15% cold). On Aksel, locally:

• the server answers later: 1.1–1.3 s at 0.3.2, 1.7–2.0 s at develop;
• warm starts did not move.

That points at the first start's pre-bundling, which the server waits for. Timing forgebook prebundle alone shows it: 0.3.2 0.85–0.89 s, develop 1.24–1.29 s.

The cause is #177. To keep the scan going past a script that does not parse, the scan's load hook now reads and parses every project script in JavaScript (parseSync), and then the scanner parses it again. This pull request keeps that behaviour and only changes when it runs:

• The pre-bundling first runs a quick scan: it reads only the story files itself, as before fix(forgebook): keep the dependency scan going past a broken component #177, and leaves every other script to the scanner.
• When a script stops the quick scan (optimizeDeps throws "Failed to scan for dependencies"), a careful scan runs, as today. It reads past the file, pre-bundles every package, and names the file. A failure naming unresolved imports is retried as before in each mode.
• A server's own scan, and a plugin used without the command, stay careful.

Numbers (Aksel at the corpus's commit, back to back, shared Mac at load 15–20)

The cold-start row is noisy: the checks were running at the same time. It was measured together with the pattern-check fix, which is a separate pull request.

How it was verified

• test/dependencyScan.test.ts: a quick scan over a broken component throws, and the careful scan then pre-bundles what the broken file imports.
• The existing scan tests (a .js story with JSX, broken components) pass unchanged.
• pnpm checks exit 0.

Not in this pull request

• About 0.15 s of the pre-bundling's growth was already there between 0.3.2 and 4f80455. I did not look for it.

🤖 Generated with Claude Code