AI & Agent Dev Bug Sandbox logo
AI & Agent Dev Bug Sandbox
Back to Radar

Next/Font/Google Fails When Google Fonts Returns Extensionless /L/Font?Kit= URLs

Google Fonts occasionally returns extensionless URLs with a format('woff2') hint. Next.js font loaders assume a file extension in the URL, causing webpack to crash with a null regex match and Turbopack to split the URL query on '&', resulting in intermittent build failures.

highConfidence 93%Next.jsAffected V16.2.12Affected V16.3.6Affected V16.4.0-Canary.40

Origin Analysis

Webpack uses a non-null assertion on a regex that requires a file extension at the end of the Google Fonts URL. Turbopack additionally parses JSON-serialized options through QString::from, which splits the URL's query string on '&', creating multiple query entries and causing a bailing check; the Rust loader also rejects URLs without an extension.
1. Clone https://github.com/jasonwbarnett/next-font-google-extensionless-url\n2. Run `npm install`\n3. Run `npm run build:webpack` and `npm run build:turbopack`\n4. The builds fail with the errors described in the issue. Control mocks using normal .woff2 URLs pass.

Fixing Code Block

Edge Case Audit

The fallback to 'woff2' assumes Google serves woff2 for the Chrome User-Agent; if a different format is served without a hint, the font file may be misclassified. The percent-encoding change in Rust may affect older Turbopack versions that decode query values differently; test thoroughly with legacy project structures. Rollback: revert the patch and pin Next.js to a version before the change if regressions occur in custom font pipelines. Also ensure existing font file hashes remain unchanged to avoid cache invalidation cascades.

Ecosystem Topology