Re-vendor fonts and switch back to the local provider for hermetic builds
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- css, javascript
- Ambito
- build-system, ci-cd, documentation
Direzione di ricerca
Esamina innanzitutto astro.config.mjs, gli asset dei font esistenti in src/assets/fonts/ e docs/overhaul/typography.md dopo che gli epic sulla tipografia avranno definito le famiglie, i pesi e gli stili. Esegui astro build con il CDN dei font bloccato, quindi confronta l’output di dist/, le licenze, gli intervalli Unicode e i preload; esamina anche il workflow mancante npm run build associato a #49.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Re-vendor the WOFF2 font files and switch astro.config.mjs from fontProviders.google() back to fontProviders.local(), so production builds stop depending on a third-party font CDN at build time.
Background
#47 (closing #24) originally vendored three Latin-subset WOFF2 binaries in src/assets/fonts/ and resolved them with the local provider, on a hermetic-build argument. That was deliberately reversed in that PR: the binaries were deleted and the faces are now resolved by fontProviders.google() at build time.
The reasoning was phase-appropriateness, not a judgement that vendoring is wrong. While the design study is still running, the font set, the weights and possibly the families themselves will churn, and every such change means re-subsetting and re-committing binaries by hand. That cost is worth paying once the typography is locked — not while it is still moving.
This is the issue that pays it back.
What this is not
It is not a privacy or "stop using Google Fonts" fix. That requirement is already met and is unaffected by the provider choice: a remote provider resolves at build time, so Astro downloads the faces during astro build and emits them fingerprinted into our own origin. Both providers were built and compared during #47 — identical @font-face rules, identical metric-adjusted fallback faces, identical Latin unicode-range, identical preloads, and zero gstatic/googleapis references in dist/ either way.
What this issue buys is narrower and worth stating plainly so it can be judged on its merits at the time:
- Hermetic builds. A release build stops needing network to reach a font CDN. It will still need network for
npm ci. - Auditable bytes. The exact files served are reviewable in-repo and change only via a reviewed commit.
- Insulation from upstream drift. Google re-cutting a face can't silently change what the site serves between two builds of the same commit.
Blocked until all epics are complete
The typography is not settled until the design work and everything that consumes it has landed, so this is gated on the full epic set:
- #38 — Epic E1: Repo foundation
- #39 — Epic E2: Astro scaffold
- #40 — Epic E3: Design
- #41 — Epic E4: Content
- #42 — Epic E5: Notes
- #43 — Epic E6: SEO, analytics, launch
#40 is the one that actually locks the face/weight set (via #26 and #27), but content and Notes can still surface a weight or an italic nothing had needed before — #33's Obsidian-flavoured elements especially. Doing this before #43 means redoing it.
Why the reversal is cheap
Components only ever reference the semantic --font-display / --font-body / --font-mono tokens in src/styles/tokens.css; nothing outside astro.config.mjs knows a font file path. The switch should touch the config, the vendored files, and the docs — nothing else. If it turns out to touch a component, that's a token-indirection leak worth fixing separately.
Two options
- Vendor the WOFF2 files in
src/assets/fonts/— what #47 originally did. Fully self-contained; requires hand re-subsetting on any change. - Pin
@fontsource/*packages and point thelocalprovider atnode_modules— keeps the binaries out of git while making the bytes integrity-hashed inpackage-lock.json, and makes weight changes a dependency bump instead of a manual subsetting job. Not tested; a build with no network still needs a warm npm cache either way.
Option 2 is probably the better end state, but pick at the time.
Acceptance criteria
-
astro.config.mjsusesfontProviders.local()for all families - Only the weights and styles the built site actually renders are vendored — no speculative extras
-
astro buildsucceeds with the font CDN unreachable (verify by blocking it, not by assuming) -
dist/output is equivalent to thegoogle-provider build: same fingerprinted files per face, metric-adjusted fallback faces present, correct preloads, zerogstatic/googleapisreferences - Latin
unicodeRangeis still declared, and its source (generated vs hand-written) is noted in a comment — #47 removed a hand-maintainedLATIN_SUBSETconstant precisely because the provider generated the identical range -
public/fonts/LICENSE-*.txtstill present and still matching the shipped faces (SIL OFL requires the licence to travel with the redistributed fonts — this obligation is independent of where the source files live) -
docs/overhaul/typography.md"Loading rules" updated. Keep the distinction it now draws — self-hosting is about what the visitor's browser fetches, not what git tracks — since conflating the two is what caused the original churn - CI builds the site (see #49 and the missing
npm run buildworkflow), so a font-resolution failure is caught rather than shipped
- Lingua principale
- HTML
- Stelle
- 0
- Fork
- 0
- Merge medio
- 8h 17m
- PR unite (30g)
- 58
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di laywill/laywill.github.io
-
design
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
laywill/laywill.github.io#186 ·
-
design
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
laywill/laywill.github.io#183 · 1 commento ·
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 74/100
laywill/laywill.github.io#135 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
laywill/laywill.github.io#106 ·
-
infra needs-william
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
laywill/laywill.github.io#35 · 1 commento ·
Tutte le issue di laywill/laywill.github.io
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
-
CS0162 "Unreachable code detected" warning from a MSBuildTemp .tmp file in every game project Apertabug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
-
area:engineering priority:p2 type:bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
jejjohnson/pyrox#234 ·
-
good first issue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
-
good first issue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
ros2/ros2_tracing#266 · 1 commento ·