turbo: [Turbopack] WebSocket connection to 'ws://localhost:3000/_next/webpack-hmr' failed
What version of Turbopack are you using?
default for next 13
What package manager are you using / does the bug impact?
pnpm
What operating system are you using?
Mac
Describe the Bug
Adding the --turbo on the package.json/scripts/dev value throws the error in the browser console.
Expected Behavior
shouldn’t throw any error in the browser console.
To Reproduce
- Create a monorepo with Turborepo.
- Locale the
package.jsonwithin the web app. - Add
--turboat the end of"dev": "next dev --turbo" - Add a new folder named
app - Create a
page.tsx(working with Javascript throws the same error) - Add a
layout.tsxfile. - run
pnpm devon the terminal. - Open the Browser and go to
http://localhost:3000. - Open the devtools, the error should be printed like:
- Removing the
--turboin thedevscript, the browser console error goes away.
Reproduction Repo
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 5
- Comments: 17 (3 by maintainers)
Turbopack’s dev server is not compatible with the builds produced by webpack. You may have a cached JS file or something that is continuing to make requests.
https://github.com/vercel/turbo/blob/56039940cdfac07b68e030da1396214962e99ceb/crates/turbopack-dev-server/src/lib.rs#L200-L209
After a lot of investigation tonight, I’ve concluded that this issue is definitely caused by the use of PNPM.
I believe (I could be wrong, I don’t write Rust) the part of Turbopack that uses HMR to fetch and update code, doesn’t resolve symlinks - which is inadvertently causing the error code above.
I really don’t have a great suggestion at the moment to resolve the issue then switching back to NPM. You can use NPM just in the nextjs directory but you’ll need to watch out for differences in workspace package declarations.
On a side note I also discovered that Next.js is doing some work already to detect the use of turborepo by looking for turbo.json. I’m hopeful one of the library authors can give us an update about this one.
I got this yesterday when working with multiple next projects. I solved it by issuing a ‘killall node’ and then restarting.
It’s curious this bug doesn’t occur outside of a monorepo setup. I can reproduce it in an almost-empty turborepo:
npx create-turbo@latest turbopack-bugnexttocanaryexperimental.appDir: trueinapps/web/next.config.jsapps/web/pagesapps/web/app/page.tsxwithexport default function() { return <div>Hello</div>; }next dev --turbo