feat: block compilation on codemod comments and ask to remove

[huozhi]

What

Introduce a SWC validator that will error for specific comments, this is introduced for the comments left by codemod. The erroring logic is the new check after users upgrade to v15 and codemod is applied, which enforces users to address all the codemod comments before dev or build. With the new dynamic async API model, any comment that is not addressed could lead to possible issues in production. Hence this linter could enforce you review the changes and remove the comments left by codemod.

Example

After running next-codemod against your codebase where it has some cases are not able to be migrated by codemod.
Next.js codemod will leave comment /* @next-codemod-error ... */ for the case that not able to handle, and this will error in dev and build as compilation error. You either delete it or just replace the prefix to @next-codemod-error, such as /* @next-codemod-ignore */ to bypass the compilation error.

• If you know the error and think it's safe to bypass now and handle it later

- /* @next-codemod-error codemod tells you something wrong with this line */
+ /* @next-codemod-ignore */

• If you know you've already addressed the issue, just delete the comment

- /* @next-codemod-error codemod tells you something wrong with this line */

Error sample in the Dev Overlay

./app/page.tsx

Error:   x You have unresolved @next/codemod comment "Manually await this call, if it's a Server Component" that need to be reviewed, please address and remove them to proceed with the build.
  | You can also bypass the build error by replacing "@next-codemod-error" with "@next-codemod-ignore".
    ,-[2:1]
  1 | export default function Page() {
  2 |   // @next-codemod-error Manually await this call, if it's a Server Component
    :  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  3 |   return <p>hello world</p>
  4 | }
    \`----

Why

This will help users have a more complete migration, and avoid accidentally go production with the unmirgated cases unhandled.

[huozhi]

• feat: block compilation on codemod comments and ask to remove #71103 👈
• canary

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @huozhi and the rest of your teammates on Graphite

[ijjk]

Failing test suites

Commit: f51fd13

pnpm test-dev test/development/acceptance-app/ReactRefreshLogBox.test.ts

• ReactRefreshLogBox app default > server component can recover from error thrown in the module

Expand output

● ReactRefreshLogBox app default › server component can recover from error thrown in the module

Expected Redbox but found none

  1102 |
  1103 |       await next.patchFile('index.js', "throw new Error('module error')")
> 1104 |       await session.assertHasRedbox()
       |       ^
  1105 |       await next.patchFile(
  1106 |         'index.js',
  1107 |         'export default function Page() {return <p>hello world</p>}'

  at Object.<anonymous> (development/acceptance-app/ReactRefreshLogBox.test.ts:1104:7)

Read more about building and testing Next.js in contributing.md.

[kdy1]

Overall it looks good

[eps1lon]

Do we also support //-style comments?

[eps1lon]

Super helpful 👍🏻

This should be documented in errors/sync-dynamic-apis.mdx

[huozhi]

Do we also support //-style comments?

Now we do (after few commits)

[eps1lon]

aside: column is off by one here. We also have other tests where we observe this. Just making a mental note for when we revisit the error overlay.

[eps1lon]

for turbopack: I like the error before the sourceframe more.