Publish react-dev-utils/openBrowser as separate package?

Is this a bug report?

No.

---

First of all, thanks for this awesome project! Your work on low-configuration tooling for the React community is a huge help for those of all skill levels.

I would like to suggest the possibility of publishing react-dev-utils/openBrowser (and maybe other things) separately as low-dependency helper packages to avoid the issue caused by the locked dependencies of react-dev-utils.

Let me outline the use case with an example:

mdx-deck uses react-dev-utils/openBrowser to reliably open the deck in the browser and focus the tab:

https://github.com/jxnblk/mdx-deck/search?q=react-dev-utils&type=Code

This is a great use of the library, but it has the downside of creating a sub-dependency on the locked dependencies of react-dev-utils, which there are many of:

https://github.com/facebook/create-react-app/blob/57ef103440c24e41b0d7dc82b7ad7fc1dc817eca/packages/react-dev-utils/package.json#L53-L77

This, combined with the use of the common ^ minor version specifier for react-dev-utils and the relatively fast cadence of releases in react-dev-utils means that any incompatibilities between any versions of any of the locked dependencies can cause situations if used with other, older packages.

For example, using a Yarn workspace with package using a pre-2.0 version of mdx-deck along with another package using version 3.0.1 of react-scripts.

In my particular case, it resulted in a cryptic “BrowserslistError: Unknown browser kaios”, caused by the locked dependency on an older version of browserslist in react-dev-utils.

I cannot downgrade browserslist via Yarn Resolutions reliably, because create-react-app@3.0.1 depends on react-dev-utils@^9.0.1. And I cannot upgrade react-dev-utils because of the minor ^ selector in the old and current versions of mdx-deck (react-dev-utils@^7.0.3 and react-dev-utils@^8.0.0 respectively).

So I’m left with using a resolution that may break things more subtly if there’s a different bug between browserslist@4.4.1 (sub-dep from mdx-deck@1.10.2 + react-dev-utils@7.0.5) and browserslist@4.5.4 (sub-dep from create-react-app@3.0.1 + react-dev-utils@9.0.1).

---

Solution

If the module was published as a separate package, it could retain its locked dependency list but with far lower possibility for incompatibilities.

I wouldn’t suggest this for every module in react-dev-utils, but it seems as if the openBrowser module is useful enough to warrant separate publishing.

In any case, thanks for listening!

Alternative Solution

Strongly recommend that package authors do not depend on the modules from react-dev-utils or provide some different alternative for them.

Also, if you know of a third option that I haven’t thought of, I’m all ears!

[mrmckeb]

Sure, it’s definitely not my decision alone - @iansu, can you chime in on the above?

[karlhorky]

The philosophy makes sense, yes.

I suppose what I’m suggesting is an exception to the philosophy for this one popular module: some kind of thing between a full, supported open source project and the current fast-shipping react-dev-utils package.

Something that can still be shipped quickly but without all of the excess weight and strange problems of locked dependencies.

Maybe this can be brought up with the rest of the team for a final decision.

If there’s no interest in making this easier to consume, we can just close this issue.