HMR broken for React when "@storybook/react": "^6.2.9" present in peer workspace [with reproduction]

[willgriffiths]

🐛 bug report

I've have issues with HMR for React in a monorepo. HMR stops working when "@storybook/react": "^6.2.9" is present in a peer workspace.

Reproduction on main branch

Run yarn start from the project root. It should start a dev server that serves the packages/hero/index.html site with HMR working but it's not.

@dioptre collected #6685 a great list of related prs 🙏. I've gone through them and linked the most relevant below with the corresponding fixes.

Things considered:

• script tag has type="module" as it should
• passing --no-hmr has no effect. The page still doesn't reload.
• Reproducing for http and https
• clearing .parcel-cache doesn't affect the reproduction
• I recommend cleaning node_modules between installs of the reproduction
• I use VS-code and this has no effect on the reproduction

🎛 Configuration (.babelrc, package.json, cli command)

• Default parcel config
• No babel config
• 3 package.json's (project root package, hero package, components package )
• Minimal dependencies apart from (parcel, react, react-dom and @storybook/react)
• yarn 3 workspaces with node_modules enabled

🤔 Expected Behavior

Run yarn start from the project root. Should start a dev server that serves the packages/hero/index.html site with HMR working.

HMR should work out of the box for a React project. When the text on in the App.tsx file is edited and saved it should trigger the text content to update in the browser local development server.

😯 Current Behavior

HMR triggered (console.clear() is called) however no change to text or styles

💁 Possible Solution

Fix 1
Fix on fix-hot-reloading-remove-storybook-react branch
The first fix I found was to remove storybook. Looks very similar to the reproduction provided here: #6334

This would suggest that dependency is interfering somewhere in the chain. In yarn, workspace dependencies can hoisted which could have conflicts.

Fix 2:
Fix on fix-hot-reloading-module-hot-accept branch
The second fix is to add module.hot.accept() as mentioned in this issue:
#6229

if (module.hot) {
  module.hot.accept();
}

🔦 Context

I'm trying to setup a monorepo with parcel in the root building all my packages. Some packages are React apps and some packages are utils and tooling.

💻 Code Sample

Reproduction on main branch fixes on branches

🌍 Your Environment

Software	Version(s)
Parcel	2.0.0-rc.0
Node	v14.17.6
npm/Yarn	3.0.0-rc.5.git.20210607.hash-017bb2fc (with node_module resolution enabled)
Operating System	MacOS

Notes

Thanks for your work. Let me know if you need help to debug further.

[mischnic]

React Fast Refresh often breaks if you have multiple instances of the react or react-refresh packages in use. I didn't actually run your reproduction, but Yarn did install 2 versions of react-refresh:
https://github.com/willgriffiths/parcel-hot-reloading-bug/blob/18426732e89549a1ab2eb022433319503bc1e7a4/yarn.lock#L12225-L12237

[willgriffiths]

Thanks for the info. That makes sense.

Is it possible to identify that and throw a warning? Or is this outside of parcel's scope?

[jeffpeck10x]

+1 re: throw a warning.

#6685 (comment)

Deck.gl does this if it finds multiple copies of luma.gl.

It would be helpful if parcel simply said this:

Multiple versions of react-refresh detected. HMR may not work as expected.

when you run parcel serve.

Even if it does not fix the issue, it will clue a user in as to why HMR is not working as expected.

In the case of storybook's react-refresh dependency, I found that this is a simple fix in the top-level package.json

"resolutions": {
  "react-refresh": "0.9.0"
}

and Storybook still works, despite yarn's warning of an incompatible version.

[spence-novata]

Does anyone have a work around for npm as the resolutions trick doesn't work without yarn

[jeffpeck10x]

@spence-novata The latest npm (v8.3.0) supports overrides:
https://github.com/npm/cli/releases/tag/v8.3.0

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.