PR #231: chore: bump next to 16.2.1

• Repository: PlagueFPS/cod-zombies
• Author: PlagueFPS
• State: closed | merged: True
• Link: https://github.com/PlagueFPS/cod-zombies/pull/231

Description (problem / solution / changelog)

Updates all next related packages to 16.2.1. Deletes the manifest.ts file as it causes a regression in HMR (see https://github.com/vercel/next.js/issues/91981), and was not needed anymore in our project regardless.

Changed files

• app/manifest.ts (removed, +0/-26)
• bun.lock (modified, +15/-15)
• next.config.ts (modified, +2/-1)
• package.json (modified, +3/-3)

PR #92034: Turbopack: exclude metadata routes from server HMR

• Repository: vercel/next.js
• Author: wbinnssmith
• State: closed | merged: True
• Link: https://github.com/vercel/next.js/pull/92034

Description (problem / solution / changelog)

What?

Metadata routes (manifest.ts, robots.ts, sitemap.ts, icon.tsx, apple-icon.tsx, etc.) were not being hot-reloaded in Turbopack dev mode — changes to those files would not be reflected on subsequent requests until a full server restart.

Why?

PR #91466 extended usesServerHmr = true in clearRequireCache() (in hot-reloader-turbopack.ts) from app-page entries only to all app-type entries (pages + route handlers). The motivation was correct: regular route handlers like app/api/hello/route.ts use Turbopack's in-place module update model and benefit from server HMR.

However, metadata routes (/manifest.webmanifest/route, /robots.txt/route, etc.) are also app-type entries but they are not suitable for in-place server HMR. When usesServerHmr = true for a metadata route, clearRequireCache() skips two critical invalidation steps:

1. Deleting the compiled chunk from require.cache
2. Calling __next__clear_chunk_cache__()

Without those steps, the old module stays in-memory and all subsequent requests to /manifest.webmanifest (etc.) return the stale content.

How?

Added an !isMetadataRoute(entryPage) guard to the usesServerHmr expression in clearRequireCache(). This restores full cache invalidation for metadata routes on every rebuild while leaving regular route handler server HMR (added in #91466) intact.

// Before
const usesServerHmr =
  serverFastRefresh &&
  entryType === 'app' &&
  writtenEndpoint.type !== 'edge'

// After
const usesServerHmr =
  serverFastRefresh &&
  entryType === 'app' &&
  writtenEndpoint.type !== 'edge' &&
  !isMetadataRoute(entryPage)   // ← metadata routes always clear the cache

isMetadataRoute('/manifest.webmanifest/route') → true (excluded from server HMR)
isMetadataRoute('/api/hello/route') → false (keeps server HMR, no regression)

Also added a regression test: metadata route hmr > reflects manifest.ts changes on fetch/refresh in the server-hmr test suite, with a manifest.ts fixture that starts at name: 'Version 0'. The test patches the file and asserts the updated JSON is returned on the next fetch.

Fixes #91981

Changed files

• packages/next/src/server/dev/hot-reloader-turbopack.ts (modified, +14/-7)
• test/development/app-dir/server-hmr/app/manifest.ts (added, +10/-0)
• test/development/app-dir/server-hmr/server-hmr.test.ts (modified, +20/-0)