Fresh scaffold: admin (and web) panel fails to load — Turbopack can't resolve @vercel/turbopack-next/internal/font/google/font

[MarkColeMukisa]

What happened

Scaffolded a brand-new project from scratch (grit generate / following the setup steps exactly), ran grit start, and opening the admin panel in the browser immediately threw a Turbopack build error — the app never renders. Ran into this while following the recent "Building an E-commerce w/ Grit" YouTube tutorial, doing exactly what it shows, so this should be reproducible by anyone following that video with a current Next.js install.

Error

Build Error
Module not found: Can't resolve '@vercel/turbopack-next/internal/font/google/font'

[next]/internal/font/google/inter_f74f0b01.module.css:250:8
Error: Module not found: Can't resolve '@vercel/turbopack-next/internal/font/google/font'
  248 |   font-weight: 700;
  249 |   font-display: swap;
> 250 |   src: url(@vercel/turbopack-next/internal/font/google/font?{%22url%22:%22https://fonts.g...
      |        ^
  251 |   unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U...
  252 | }
  253 | @font-face {

Import map: Resolved by import map

Import trace:
  Server Component:
    [next]/internal/font/google/inter_f74f0b01.module.css
    [next]/internal/font/google/inter_f74f0b01.js
    ./apps/admin/app/layout.tsx

Next.js version: 16.3.3 (Turbopack)

Root cause

The generated apps/admin/app/layout.tsx (and the equivalent apps/web/app/layout.tsx) import fonts via next/font/google:

import { Inter, JetBrains_Mono } from "next/font/google";

const inter = Inter({ subsets: ["latin"], variable: "--font-display", weight: ["400", "500", "600", "700"] });
const jetbrainsMono = JetBrains_Mono({ subsets: ["latin"], variable: "--font-mono", weight: ["400", "500", "600"] });

next dev in this Next.js version defaults to Turbopack, and Turbopack's Google-fonts loader has a known bug/regression where it can't resolve its own internal @vercel/turbopack-next/internal/font/google/font module (see e.g. vercel/next.js discussions #61886 and #81721, and several other open reports across the ecosystem). It reproduces consistently here, not just intermittently — the admin dev script already does rm -rf .next on every start, so it isn't a stale-cache issue.

Since both scaffolded apps (apps/admin, apps/web) use next/font/google out of the box, this hits every fresh grit generate/grit start on affected Next.js versions, not just this project — anyone following the current YouTube walkthrough from a clean scaffold would hit it too.

Environment

• OS: Windows 11 Home 10.0.26200
• Next.js: 16.3.3 (installed; package.json pins "next": "^16.1.6")
• Package manager: pnpm 10.0.0 (turborepo monorepo)
• React: 19.2.7
• Bundler: Turbopack (default for next dev in this Next.js version)

Workaround used

Switched both apps' dev scripts to force webpack instead of Turbopack, which sidesteps the buggy code path entirely:

- "dev": "rm -rf .next && next dev --port 3001",
+ "dev": "rm -rf .next && next dev --webpack --port 3001",

(and the equivalent for apps/web's port 3000). This resolves the build error and the admin/web apps load normally.

Suggested fix

A few options worth considering for the generator templates:

1. Pin the scaffolded next dependency to a version range known not to hit this Turbopack font-loader bug, or
2. Ship the dev script with --webpack until the upstream Turbopack bug is resolved, or
3. Self-host the fonts via next/font/local in the generated templates instead of next/font/google, avoiding Turbopack's remote-font-fetch code path altogether.

Happy to open a PR against the templates if that's useful — let me know which direction you'd prefer.

[MUKE-coder]

Fixed in v3.183.0 — the scaffolded dev scripts now pass --webpack for both apps/admin and apps/web, which is the workaround you validated. Thank you for the write-up; the root-cause analysis and the three options saved a lot of time.

One thing worth reporting back, because it changes how we should think about the long-term fix: I could not reproduce it here. A project on the exact version you hit, next@16.3.3, with the same next/font/google imports and Turbopack, ran all day without the error. So it is machine-dependent rather than universal, which is why it survived this long unreported.

That makes --webpack a workaround rather than a correction, and it ships with a comment in package.json saying exactly that and when to remove it:

--webpack is a workaround for an upstream Turbopack bug: its Google-fonts loader fails to resolve its own @vercel/turbopack-next/internal/font/google/font module, and the app never renders (grit#77). It does not reproduce on every machine, which is why it survived so long. Remove the flag once Turbopack ships the fix and dev gets faster again.

On your option 3, self-hosting via next/font/local: I agree it is the more robust answer, since it removes the remote-font code path entirely rather than routing around it. I did not take it in this release because it means committing the woff2 files into the scaffold templates, and I would rather ship you something that works today than hold the fix for that. It stays on the list.

If you still want to open a PR, the local-font route is the one I would take. internal/scaffold/admin_files.go and web_files.go hold the layouts.

Same release also moves both apps to Tailwind v4, so a fresh scaffold changed a fair bit; worth a clean grit new rather than an upgrade if you are comparing.