Google Fonts Laravel Package

Product Decisions This Supports

• Privacy/GDPR compliance roadmap: Self-hosting Google Fonts eliminates third-party requests to Google servers, a common legal and procurement concern. This package automates the fetch-lock-serve pipeline rather than requiring manual font management.
• Web performance budget decisions: Font subsetting (text parameter), preload hints, and CSS merging directly map to Core Web Vitals optimizations (LCP, CLS). PMs can use this to reduce initial payload without a separate performance-engineering project.
• Build vs. buy: This is effectively a "buy" (or adopt OSS) answer to "how do we self-host fonts?" — cheaper than building a custom font pipeline, and now feature-complete enough (caching, validation, dry-run) to be production-viable.
• Feature roadmap inputs for 0.3+: The release signals maturity of the core workflow; next bets likely include variable-font support, multi-provider font sources (beyond Google), and framework-agnostic adapters.
• Ops/CI decisions: Dry-run mode and progress bars improve developer ergonomics for teams automating font locking in CI; API response caching reduces build-time flakiness and rate-limit exposure.
• Risk assessment: Environment-agnostic YAML config (when@prod/when@dev) is a deliberate move away from runtime env checks — good for predictability, but teams relying on runtime overrides must migrate.

When to Consider This Package

Consider adoption when:

• You are on a Symfony stack using AssetMapper (or a Laravel/Symfony app willing to adopt it as a companion) and need self-hosted Google Fonts with minimal glue code.
• You have a privacy/compliance requirement to remove Google Fonts CDN calls.
• Your performance goals include font subsetting and preload hints for above-the-fold text.
• You need a repeatable, scriptable pipeline (gfonts:lock, gfonts:import, gfonts:status, gfonts:prune) suitable for CI/CD.
• You value quality signals: >93% test coverage, PHPStan Level 9, all Psalm issues resolved, integration tests spanning scan-to-render.

Look elsewhere when:

• You need variable/anatomy-level font optimization (pyftsubset, unicode-range slicing) beyond the text subsetting offered here.
• You are on a non-PHP stack, or a Laravel app that has no appetite for Symfony-style AssetMapper conventions (the release is explicitly Symfony-centric).
• You require multi-provider font sourcing (Adobe Fonts, Fontsource, self-hosted custom webfonts).
• You need a CDN-first architecture where any local font pipeline adds negligible value.
• You cannot tolerate 0.x API churn — this is a pre-1.0 package with structural changes (manifest schema, config model) still landing between minor releases.

How to Pitch It (Stakeholders)

For executives: This package lets us stop shipping user requests to Google for fonts — a privacy and compliance win — while also making pages faster by trimming unused font characters and preloading the fonts that matter. It's automated, tested, and low-risk to adopt: we download fonts once, generate optimized CSS, and serve them from our own infrastructure. It replaces a manual or custom-built process and is mature enough to run in production.

For engineering leadership: Release 0.2.0 turns this from a utility script into a production-grade tool: configurable API caching (default 1h), dry-run + progress bars for safe CI use, gfonts:status/gfonts:prune for lifecycle management, and environment-agnostic YAML config. Quality bar is high — >93% coverage, PHPStan Level 9, Psalm clean, integration tests across the full scan→render workflow. Symfony 7.1 Filesystem::readFile() forward-compat with fallback shows maintenance hygiene. Main caveats for the team: pre-1.0 churn risk (manifest format changed this release), and it's Symfony/AssetMapper-oriented — confirm fit before adoption. Recommend a spike on a representative app to validate the new config model and prune workflow.