Weave Code
Google Fonts Laravel Package
neuralglitch/google-fonts
Laravel package for self-hosting Google Fonts: download font files locally, generate CSS, and serve them from your app. Avoid external Google requests, improve privacy and GDPR compliance, and boost performance with cached local assets.
Google Fonts integration for Symfony
Frequently asked questions about Google Fonts
- Does neuralglitch/google-fonts work with Laravel?
- The package is described as a Google Fonts integration for Symfony, and its documented workflow is built on Symfony primitives such as AssetMapper, Twig template scanning, and a Flex recipe. There is no confirmed Laravel adapter, and the 0.2.0 release notes reference only Symfony components. You can install it in a Laravel app through Composer, but expect to write a custom adapter or consume the generated manifest manually. Treat Laravel support as unproven until the maintainer states supported frameworks explicitly.
- How do I install and configure neuralglitch/google-fonts?
- Install it with Composer using composer require neuralglitch/google-fonts; on Symfony the Flex recipe wires up the configuration automatically. Configuration lives in YAML, including when@prod and when@dev blocks that scope behavior per environment. After installing, you run the lock and import commands to download font binaries and generate the CSS. There is no documented Laravel service provider or config publishing step, so Laravel setup would be manual.
- Which PHP and framework versions are supported?
- The supported-version matrix is not fully documented, and the package is at 0.2.0 with no semver contract yet. Quality signals are strong for this stage: over 93% test coverage, PHPStan Level 9, and all Psalm ERROR/INFO issues resolved. A Filesystem::readFile() compatibility shim with a fallback suggests the supported range is still moving. Check composer.json constraints before installing, and note that Laravel version support is unconfirmed.
- How does the font self-hosting workflow actually work?
- A build-time scanner looks for google_fonts() calls in your templates, resolves the requested families and weights against the Google Fonts catalog, and downloads the binaries into your project. It then generates optimized CSS with relative @font-face URLs plus a manifest that the asset pipeline consumes. Requested weights are validated against what a family actually publishes, and the manifest records only the weights that were really downloaded. Generated @font-face declarations are merged into a single CSS file per font.
- Which console commands does the package provide?
- gfonts:lock resolves and locks the font binaries, gfonts:import downloads and imports them, gfonts:status reports whether the project is configured and locked correctly, and gfonts:prune removes unused artifacts. Both gfonts:lock and gfonts:import accept a --dry-run flag so you can rehearse the cycle in CI before committing binaries. These are the documented entry points for the build workflow. They are Symfony console commands, so invoking them from Laravel would need verification.
- Can I use it with Vite and Blade instead of AssetMapper and Twig?
- Not out of the box. The template scanner and asset-path logic assume Symfony's AssetMapper assets directory and relative ./font.woff2 URLs in the generated CSS. Vite emits hashed filenames, so the manifest entries and CSS paths will not map cleanly onto its output. A Laravel integration likely requires a custom adapter or manual consumption of the generated manifest inside your Vite config.
- Does this package help with GDPR and privacy compliance?
- Fonts are downloaded at build time and served from your own domain, so visitors' browsers never make requests to fonts.googleapis.com or fonts.gstatic.com. That removes a third-party data transfer commonly cited in GDPR assessments of Google Fonts usage. Keep in mind the fonts are still fetched from the Google Fonts API during the build, so the dependency is moved rather than eliminated.
- Is version 0.2.0 safe to run in production?
- It is pre-1.0, so there is no semver guarantee, and 0.2.0 already changed observable output: manifest weight reporting, one CSS file per font, and relative CSS font paths, all of which break consumers that parse those artifacts. The Google Fonts API remains a hard build-time dependency, and the new response cache with a one-hour default TTL mitigates rate limits and outages but introduces stale-catalog and cache-invalidation concerns. The upside is that failures are contained to the build rather than the request path, which limits blast radius. Pin the version and read release notes before upgrading.
- How do I test the font pipeline in CI before committing binaries?
- Use --dry-run on gfonts:lock and gfonts:import to rehearse the full cycle without committing font files, and run gfonts:status to assert the project is configured and locked correctly. The package ships integration tests that cover the template-scan-through-render path, and coverage is above 93%, so it is reasonable to depend on in a pipeline. Pair those checks with a diff confirming the generated CSS and manifest match what is committed.
- What are the alternatives for self-hosting Google Fonts in Laravel?
- For Laravel, npm-based options such as @fontsource packages pair naturally with Vite and skip PHP-side build tooling entirely. Laravel-specific packages that download and cache Google Fonts CSS also exist, and you can always self-host manually by placing woff2 files in public/ and writing your own @font-face rules. This package is a strong fit on Symfony with AssetMapper, but on Laravel the alternatives usually involve less friction.
Weaver
How can I help you explore Laravel packages today?