fix(playground): resolve dev server crash caused by Next.js 16 upgrade

[mishop-15]

Context
The playground package was recently upgraded from Next.js 14 to 16.1.5 (via Dependabot ~2 days ago).

The Issue
Next.js 16 enables Turbopack by default for development. However, this project uses a custom webpack configuration in next.config.mjs. This causes npm start to fail immediately with a conflict error because Next.js cannot use both Turbopack and a custom Webpack config simultaneously without an explicit flag.

The Fix

1. Updated the start script in playground/package.json to add the --webpack flag. This forces Next.js to use the existing webpack config.
2. Removed the deprecated eslint key from next.config.mjs (which is no longer supported in Next.js 16 and was throwing warnings).
3. Added next.config.mjs to the include list in playground/tsconfig.json to resolve local ESLint parsing errors.

Verification
Validated that npm start now successfully launches the playground on http://localhost:3000.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[mishop-15]

Hi @AceTheCreator, I noticed the playground build was broken after the recent Dependabot upgrade to Next.js 16 (Turbopack conflict). I've submitted this fix to resolve the crash and clear up the config warnings so the dev server runs smoothly again. Ready for review whenever you have a moment!

[AceTheCreator]

Thanks for fixing this. One note from my review: since Next.js 16 ships with Turbopack, I think we should use it instead of Webpack. I’d suggest removing the Webpack configuration and switching fully to Turbopack.

[mishop-15]

Thanks for the review! I'll go ahead and remove the custom Webpack configuration and switch the dev script to use turbo. Updating the PR shortly!

[mishop-15]

Thanks for fixing this. One note from my review: since Next.js 16 ships with Turbopack, I think we should use it instead of Webpack. I’d suggest removing the Webpack configuration and switching fully to Turbopack.

I’ve updated the script to use --turbo, but I'm hitting a build error because the parser dependencies rely on Node.js modules like fs. Unlike Webpack (which let us just set fallback: false), Turbopack doesn't polyfill these by default yet.

To resolve this, I would need to implement a workaround since Turbopack lacks the fallback: false configuration that Webpack uses to ignore server-side modules. The solution involves creating a small, empty mock file for fs and configuring an alias in next.config.js to redirect all fs imports to this local file. Are you comfortable with me adding this mock to the repository, or should we prefer to stick with Webpack.

[SHUBHANSHU602]

Please mention issue number in the PR description

[mishop-15]

Please mention issue number in the PR description

There isn't an issue associated issue raised with this. I encountered while setting up the project locally.

[AceTheCreator]

Thanks for fixing this. One note from my review: since Next.js 16 ships with Turbopack, I think we should use it instead of Webpack. I’d suggest removing the Webpack configuration and switching fully to Turbopack.

I’ve updated the script to use --turbo, but I'm hitting a build error because the parser dependencies rely on Node.js modules like fs. Unlike Webpack (which let us just set fallback: false), Turbopack doesn't polyfill these by default yet.

To resolve this, I would need to implement a workaround since Turbopack lacks the fallback: false configuration that Webpack uses to ignore server-side modules. The solution involves creating a small, empty mock file for fs and configuring an alias in next.config.js to redirect all fs imports to this local file. Are you comfortable with me adding this mock to the repository, or should we prefer to stick with Webpack.

Yes, please go ahead, cuz it seem that's the recommended approach for fallback in turbopack 👍🏾

[mishop-15]

@AceTheCreator I gave the Turbopack approach a try but hit some walls. Started by creating lib/empty.ts with mocks for fs, util, and path, then configured turbopack.resolveAlias. The mock file grew to 50+ exports as different dependencies needed different Node functions.

The bigger issue is that AsyncAPI's parser dependencies (@asyncapi/avro-schema-parser, @stoplight/spectral-runtime, etc.) they use them for binary serialization and file operations. Empty mocks cause runtime failures because these libraries expect real Node.js functionality that can't be faked.

My original Webpack solution (--webpack flag) handles this cleanly with fallback: false.

[AceTheCreator]

@AceTheCreator I gave the Turbopack approach a try but hit some walls. Started by creating lib/empty.ts with mocks for fs, util, and path, then configured turbopack.resolveAlias. The mock file grew to 50+ exports as different dependencies needed different Node functions.

The bigger issue is that AsyncAPI's parser dependencies (@asyncapi/avro-schema-parser, @stoplight/spectral-runtime, etc.) they use them for binary serialization and file operations. Empty mocks cause runtime failures because these libraries expect real Node.js functionality that can't be faked.

My original Webpack solution (--webpack flag) handles this cleanly with fallback: false.

Yeah, you're right. I totally forgot about the Parser 😄

Let's use the webpack flag for dev

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud