Link to the code that reproduces this issue

https://github.com/donkeyote/next-tests-typecheck

To Reproduce

1. run pnpm install && pnpm build && pnpm start
2. Inspect chunks filenames in view-source:localhost:3000 — filenames contain ~ characters
3. Deploy behind any WAF that flags ~ in URL paths
4. App fails to load — WAF returns 400 with text/html instead of JS.

Current vs. Expected behavior

Turbopack (16.2.x) generates chunk filenames containing ~ (tilde) characters,
e.g. _next/static/chunks/0259pyb~8-2~v.js.

Expected: Chunk filenames use only URL/WAF-safe characters (alphanumeric, -, _, .)
Actual: Chunk filenames contain ~ which is flagged by enterprise WAF rules,
causing a 400 response with text/html instead of application/javascript.
The browser refuses to execute the file and the app breaks entirely.

Previous behavior in 16.1.x (hex hashes) was WAF-compatible:
d0b8996cb3d22274.js
96c0a41d0f0dc35b.js

New behavior in 16.2.x (tilde format) is blocked:
0259pyb8~2v.js
09072fu2~0v1.js

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Enterprise
  Available memory (MB): 64957
  Available CPU cores: 14
Binaries:
  Node: 24.14.0
  npm: 11.9.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 16.2.2
  react: 19.2.4
  react-dom: 19.2.4
Next.js Config:
  output: N/A

Deployment: behind enterprise WAF
Issue reproduced on: 16.2.x (not present in 16.1.5)

Which area(s) are affected? (Select all that apply)

Turbopack

Which stage(s) are affected? (Select all that apply)

next build (local)

Additional context

This is the issue that was posted here #92250 - I'm another person who experienced it - I just added an example repo with reproduction.

The WAF returns a 400 response with text/html for any request to /_next/static/chunks/*.js filenames containing ~. The browser then refuses to execute the file due to MIME type mismatch, breaking the app entirely.

This is not reproducible on Vercel (no WAF layer), which likely explains why this hasn't been widely reported despite affecting any self-hosted enterprise deployment behind standard WAF rulesets.

The issue is not present in 16.1.x where Turbopack used hex-only chunk filenames. The ~ character appears to have been introduced as part of Turbopack's compressed chunk naming format in 16.2.x.

Workaround: next build --webpack avoids the issue but opts out of Turbopack performance gains.

Requested: a Turbopack config option to restrict chunk filename characters to WAF-safe alphanumerics (similar to webpack's output.chunkFilename).