feat(core): the renderer's font pipeline is importable from @hyperframes/core/fonts/embed - #5041

What changes for a person

A preview that wants to show exactly the fonts a render will use can now call the renderer's own font pipeline, from @hyperframes/core, without installing the producer:

import {
  normalizeSystemFontPrimaryFamilies,
  injectDeterministicFontFaces,
} from "@hyperframes/core/fonts/embed";

const html = await injectDeterministicFontFaces(normalizeSystemFontPrimaryFamilies(source));

That is the same pair, in the same order, the producer runs when it compiles a render (htmlCompiler.ts, compileForRender). Until now it lived only in @hyperframes/producer, so the HyperFrames desktop app's preview had to install the whole renderer to match it.

Install footprint

Clean installs on Linux from the release tarball (pnpm pack), du -sm node_modules:

The desktop app already depends on @hyperframes/core, so the pipeline costs it about 2 MB (wawoff2 and its one dependency, plus the embedded font data) instead of 203 MB.

The move

One owner, no copy left behind:

• packages/producer/src/services/{deterministicFonts,fontCompression,authoredGoogleFonts,fontData.generated}.ts and their 15 test files move to packages/core/src/fonts/ (git renames).
• The font-data generator and its build step move to packages/core/scripts/; core's build runs build:fonts the way the producer's did. wawoff2 and the @fontsource/* packages move with them. The @fontsource/* packages are only read by the generator, so they become core devDependencies; 11 of them were runtime dependencies of the producer.
• Two node-only subpaths, declared in package-subpaths.json with environments: ["bun", "node"]: @hyperframes/core/fonts/embed (the pipeline) and @hyperframes/core/fonts/embedded-data (the font data the distributed planner hashes). Core's root entry does not pull in either; the pipeline reads the disk cache and uses node:fs, node:os and node:crypto.
• The producer imports both from core and keeps re-exporting the same names from @hyperframes/producer, so its public API is unchanged. Its own bundle still contains the pipeline.
• The CLI's Studio server and the Studio dev server load the pipeline from core's source instead of the producer's.

Behaviour

Unchanged. The one new option is logger on injectDeterministicFontFaces: core has no logger of its own, so the messages the pipeline used to send to the producer's logger go to the caller's logger when given, and otherwise to stderr in the same [WARN] / [INFO] format the producer's console logger writes (never stdout). The producer passes its own logger, so its output is the same as before.

Tests

• The 15 moved test files ran under bun test in the producer; core runs vitest. They now import from vitest and run in a Node environment (@vitest-environment node; core's default is jsdom). Two bun-only matchers became vitest ones (toBeString, toStartWith). The fail-closed test now captures the default logger's console.warn.
• "shares one elapsed-time budget across multiple font resources" failed once in three full runs under vitest's parallel workers: it timed a 100 ms budget with real clocks, and a millisecond of drift between the abort timer and Date.now() let a second attempt start. It now runs with Date and setTimeout faked, so the budget is read from the test's clock. 16 files, 216 tests pass in 5 of 5 full runs on this code.
• Producer unit lane (bun and vitest): pass. Core, producer, CLI and Studio typechecks: clean. verify:packed-manifests after a full workspace build: 157 packed exports resolved, clean consumer install and Node execution pass.
• A clean install of the packed core tarball imports @hyperframes/core/fonts/embed, runs both functions on a page that asks for Inter, and embeds Inter's face; the logger option receives the pipeline's message.

.fallowrc.jsonc: the moved files bring their existing duplication and one inherited complexity finding with them, which fallow reads as new because the paths changed. They are listed under duplicates.ignore and health.ignore with a "moved from" note, as the earlier parsers move did; parseFontFamilyValue keeps its complexity with an inline ignore.

No visible change

The only Studio change is two lines in packages/studio/vite.adapter.ts: the dev server loads the same font function from its new home in core. Preview and render output are unchanged.