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

[karlhorky]

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]

Hi @karlhorky, thanks for the support.

Have you considered using the open package itself? It might cover off what you need.

Edit: You could also consider an approach like the one outlined here? https://github.com/npm/npm/issues/340#issuecomment-529413

A little hacky... but would work for you.

[karlhorky]

Hey @mrmckeb, thanks for the suggestions.

It's not really about me or my own packages - more about the community, which may have strong feelings about using the module from react-dev-utils instead of an alternative like open. Some may of course consider this as an alternative, but I think the normal, cowpath-paved way of installing react-dev-utils will stick around in a non-insignificant way.

Is the CRA team against publishing this separately?

[mrmckeb]

The team have historically been against people relying on our internal files, only because we could change them at any time. If we renamed that file, your project would need to be updated (and may break for some users).

That would be solved if we publish of course, but then that also means we need to support that package and again, we now have to think a lot more carefully about any changes we make - as it's no longer just there to support our application.

I hope that makes sense?

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

[mrmckeb]

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

[karlhorky]

Friendly ping @iansu :)