In a Next.js App Router app, calling `Inter({ subsets: [chosenSubset] })` from `next/font/google` inside a component body fails the build, even though `chosenSubset` holds a valid string. Why does next/font insist the loader be called at module scope with literal arguments?

## next/font is not a function you call It looks like a function call, and that is the source of the confusion: ```ts import { Inter } from 'next/font/google' const inter = Inter({ subsets: ['latin'], weight: '400' }) ``` But nothing named `Inter` runs at runtime. `next/font` is implemented as a compiler transform wired into Next's build. When the compiler encounters this call it does the work itself: resolves the family, fetches the matching font binaries for the requested weights, styles and subsets, writes them into the application's static output, generates `@font-face` CSS plus the class rules, and replaces the call expression with a plain object holding the generated `className`, `style` and — if requested — `variable`. Everything about that pipeline happens *before* any code executes. That is precisely why the runtime cost is a single same-origin font request and no JavaScript. ## Why literals, specifically A compiler transform can only act on what the source text says. Consider the rejected form: ```ts const chosenSubset = someCondition ? 'latin' : 'cyrillic' const inter = Inter({ subsets: [chosenSubset] }) // build error ``` To do its job the compiler would have to evaluate `someCondition` — which may depend on an environment variable, a network call, or user input that does not exist at build time. There is no correct answer it could pick. Rather than silently guessing (say, downloading every subset, or defaulting to latin and quietly shipping missing glyphs), Next refuses the input and reports a build error saying the values must be explicitly written literals. The same reasoning explains the module-scope rule. A call inside a component body implies it happens per render, with whatever arguments that render supplies. The transform has no per-render step to hook into; there is one build and one set of emitted font files. So Next requires the call to sit at module top level, assigned to a `const`, which is a shape it can statically identify, evaluate once, and rewrite. The restriction extends further than people expect. Spreading a variable object (`Inter({ ...options })`), computing a weight from a constant elsewhere, or reading a value from a config module all fail for the same reason: the compiler would need to run code to learn the value. ## What you do instead The fix is always to move the choice from *load time* to *apply time*. Declare every face you might need, statically, and let runtime pick which class to attach: ```ts // app/fonts.ts import { Inter, Roboto_Mono } from 'next/font/google' export const sans = Inter({ subsets: ['latin'] }) export const mono = Roboto_Mono({ subsets: ['latin'] }) ``` ```tsx // somewhere in a component <p className={useMonospace ? mono.className : sans.className}>…</p> ``` Both fonts are fetched and emitted at build time; the runtime decision is only which generated class name lands on the element. This is a genuine tradeoff and worth naming in an interview: you have traded "load exactly the font this user needs" for "the set of fonts is fixed and known", and you pay for any face you declared but rarely apply. If a locale-specific face is only needed on a handful of routes, declare it in a module those routes import rather than in the root layout, so its files are only associated with — and preloaded on — pages that actually use it. ## Why this design is a feature, not a limitation Because the configuration is static, several good properties follow. A misspelled family or an unpublished weight fails the build rather than degrading silently in production. The build knows exactly which font files exist, so it can emit accurate preload hints and correct fallback metrics. And no font-loading logic ships to the client at all — there is no JavaScript deciding what to fetch, which is what makes the whole feature zero-runtime. The mental model to carry into the interview: `next/font` sits in the same family as other build-time-resolved constructs — the arguments are part of the build's input, not part of your program's state. Once you hold that, the error message stops being mysterious and the workaround is obvious.