RFC: react-refresh could be expressed as a peer dependency to prevent duplication + non-function

[benmosher]

💬 RFC

I had a similar issue to others with other packages in my monorepo causing a version other than 0.9.0 of react-refresh to be installed, and causing it to be duplicated (ergo non-functional) vis-a-vis the @parcel packages that need it.

Were it instead a peerDependency of the different @parcel/* sub-packages that use it, Yarn would not have installed a separate copy for each @parcel package.

I propose making it instead a peerDependency and having react-refresh appear either as a devDependency of the Parcel-built package itself, or of e.g. @parcel/config-default or whatever other package is explicitly referencing each react-refresh-engaged package.

🔦 Context

I have been using Parcel for months and loving it, but React HMR has never worked and I only just today finally found similar issues that pointed me to this as the root cause. Just as with the linked issue above, I had Storybook installed, as well as an instance of react-scripts, both of which were hoisting react-refresh@0.8.3 to the root workspace node_modules, so each of the @parcel/* packages that depend on react-refresh had their own copy of 0.9.0.

I would be glad to work on a PR for this but would like to know first if y'all are amenable, and also whether you have counterarguments / historical context for retaining react-refresh explicitly as a true dependency of each relevant package.

Parcel is great, much appreciated -- just want to help out with this minor frustrating corner.

[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.