Bug description
Since the Next.js 16 upgrade, package.json's dev/build scripts explicitly pass --webpack to avoid Next 16's new Turbopack default, which would otherwise silently ignore next.config.ts's custom webpack config (needed for FFmpeg.wasm to load). This gotcha is explained only in a code comment in next.config.ts:10-12 — nowhere in CONTRIBUTING.md's "Development Tips" section (which is exactly where a contributor debugging a weird build issue, or "cleaning up" what looks like a redundant flag, would look).
Steps to reproduce
grep -i "turbopack\|webpack" README.md CONTRIBUTING.md → no hits outside next.config.ts itself.
Expected behavior
A short note in CONTRIBUTING.md's Development Tips explaining why --webpack is there and what breaks if it's removed.
Actual behavior
Undocumented outside a code comment — a contributor could plausibly "simplify" the scripts and silently break FFmpeg loading.
Bug description
Since the Next.js 16 upgrade,
package.json'sdev/buildscripts explicitly pass--webpackto avoid Next 16's new Turbopack default, which would otherwise silently ignorenext.config.ts's custom webpack config (needed for FFmpeg.wasm to load). This gotcha is explained only in a code comment innext.config.ts:10-12— nowhere in CONTRIBUTING.md's "Development Tips" section (which is exactly where a contributor debugging a weird build issue, or "cleaning up" what looks like a redundant flag, would look).Steps to reproduce
grep -i "turbopack\|webpack" README.md CONTRIBUTING.md→ no hits outsidenext.config.tsitself.Expected behavior
A short note in CONTRIBUTING.md's Development Tips explaining why
--webpackis there and what breaks if it's removed.Actual behavior
Undocumented outside a code comment — a contributor could plausibly "simplify" the scripts and silently break FFmpeg loading.