Playground fails to start with Next.js 16 (Turbopack) - Module not found: Can't resolve 'fs'

[Satya900]

🐛 Description

When running npm start in the playground directory, the build fails with the following error:

Module not found: Can't resolve 'fs'

The error originates from dependencies such as avsc, which are pulled in via @asyncapi/parser.

This happens because Next.js 16 uses Turbopack by default in development mode, and Turbopack does not respect the existing Webpack configuration defined in next.config.mjs that mocks the fs module (fs: false).

---

🔁 Steps to Reproduce

1. Navigate to the playground directory

2. Run:

   npm start

3. Observe the build failure with:

   Module not found: Can't resolve 'fs'
   

---

✅ Expected Behavior

The playground should start successfully in development mode, consistent with the behavior when using Webpack.

---

⚠️ Workaround

Running Next.js explicitly with Webpack resolves the issue temporarily:

npx next dev --webpack

---

💡 Possible Solutions

We should consider one of the following:

1. Update next.config.mjs to include a Turbopack-compatible configuration that aliases or mocks the fs module.
2. Update the npm start script to explicitly use --webpack until proper Turbopack support is added.

---

🖥️ Environment

• OS: Windows
• Node.js Version: 25.5.0
• Next.js Version: 16.1.5

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup 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.

[Satya900]

@Adi-204 please review this issue if it is valid or not

[Athaxv]

Hi @Satya900 ,

I’ve successfully reproduced and confirmed this is a valid issue. The problem is that Next.js 16 Turbopack is incompatible with the current playground configuration, specifically in how Node.js modules (fs, path, util) are resolved.

Adding the --webpack flag to the start script fixes the issue immediately.

But before opening a PR, it would be good to confirm with the maintainers on the preferred direction. Since Turbopack was the initial approach and offers faster dev builds, we should ideally aim to continue using Turbopack rather than falling back to Webpack.

If there are any difficulties in fixing the Turbopack compatibility with these modules, I’d be happy to help once the preferred direction is confirmed.