Next.js 16 asks a glibc 2.28 host for GLIBC_2.29 before it reads next.config.ts

Symbol versions are a hard match. An SSH session on the account returned `glibc 2.28` from `getconf GNU_LIBC_VERSION` ^[4]. The SWC binary wanted the versioned interface named `GLIBC_2.29` out of the math library `libm.so.6` ^[19]. One minor release apart ^[1]. SWC is the compiler Next.js uses to transform application code, and its native binaries depend on the operating system they run on ^[18]. Whether the compiler loads at all is a property of the host. The author notes that neither changing npm dependencies nor picking a newer Node.js version necessarily upgrades the Linux libraries underneath them; replacing glibc by hand in a managed hosting account was not an appropriate fix ^[20]. The SSH reading does not prove the builder runs the same image, though the build log named the missing interface on the builder itself ^[5]. Which Node.js patch and npm versions the remote builder used stayed open ^[21].

A later log message referred to a missing generated configuration module, and Hostinger's automated analysis suggested deleting a corrupted temporary configuration file ^[16]. According to the write-up, that explanation did not account for the earlier native-library errors, and clearing the Next.js cache would not provide the missing system-library interface ^[17].

The rename is the smaller change. The `.mjs` extension identifies a JavaScript module Node.js can load without transforming TypeScript syntax, which is what keeps configuration loading clear of the compiler, and Next.js supports the format ^[6]. The type import came out and the `NextConfig` annotation on `const nextConfig` with it ^[22]. A JSDoc `@type` comment keeps editor type information ^[9]. The settings body was preserved, security headers and a conditional Docker output setting included ^[7], and the application code stayed TypeScript ^[8].

The second change splits the work between builders. WASM bindings did load, and webpack proceeds with the SWC WASM fallback ^[11]; the plain script sent the build to Turbopack, which reported that it requires native bindings ^[4]. The switch is a CLI argument: the write-up records that no `webpack: true` setting, no Next.js downgrade and no manual glibc upgrade were needed ^[12]. Hostinger's panel stayed as it was, with build command `npm run build`, output directory `.next` and Node.js 22.x ^[14].

Two conditions have to hold before this transfers to another account. The build log has to name the SWC native load failure, and the refusal has to come from Turbopack itself, since the fallback only works while the WASM bindings still load ^[10]. The flag also sits in the committed build script, so every `npm run build` follows the host onto webpack, local runs included ^[3]. I would keep the one script.