Completion roadmap for react-scripts@2.0
See original GitHub issueHey everyone! We know progress on react-scripts@2.0
has been stagnating for a while.
We put together a lofty set of goals when we first started v2. The scope of these changes have proven themselves to be too large to effectively polish everything and create a stable build.
To remediate this, we’re going to reduce the scope of v2, polish completed features, and release v2 as stable within the next two (2) weeks.
Action Plan
Our proposed plan of action is as follows (in no particular order):
-
✅ Fix vendor chunking (https://github.com/facebook/create-react-app/issues/4977, https://github.com/facebook/create-react-app/issues/4769, https://github.com/facebook/create-react-app/issues/4633, https://github.com/facebook/create-react-app/issues/4632)
- Vendor chunking exhibits undesirable behavior when used in combination with code splitting. The application dependencies used by every application chunk end up in a single vendor bundle, effectively nullifying the value of code splitting.
- We would like to create a vendor chunk per application chunk. If this behavior cannot be achieved, we will revert vendoring and place dependencies in the application chunks.
- As an alternative to the former, we may only enable the vendor chunk when no code splitting is used in your application (if possible).
-
✅ Switch to Terser (https://github.com/facebook/create-react-app/issues/4948, https://github.com/facebook/create-react-app/issues/4902, https://github.com/facebook/create-react-app/issues/4711, https://github.com/facebook/create-react-app/issues/4692, https://github.com/facebook/create-react-app/issues/4683, https://github.com/facebook/create-react-app/issues/4665, https://github.com/facebook/create-react-app/issues/4329, https://github.com/facebook/create-react-app/issues/4116, https://github.com/facebook/create-react-app/issues/4100)
- Uglify-ES has been the source of a lot of problems, and is no longer maintained. We should switch to Terser (the more maintained fork of Uglify-ES) to fix obscure bugs resulting from production builds.
-
✅ Revert monoreport support (https://github.com/facebook/create-react-app/pull/3741, https://github.com/facebook/create-react-app/pull/3997, https://github.com/facebook/create-react-app/pull/4001) because there’s too many issues (https://github.com/facebook/create-react-app/issues/4569, https://github.com/facebook/create-react-app/issues/4410, https://github.com/facebook/create-react-app/issues/4249, https://github.com/facebook/create-react-app/issues/4092, https://github.com/facebook/create-react-app/pull/4570, https://github.com/facebook/create-react-app/issues/3031, https://github.com/facebook/create-react-app/pull/3967)
- We would’ve loved to figure out all of the ergonomics around monorepo support, but it turns out it’s just too difficult.
- We’re going to revert monorepo support in favor of consuming library packages via
nwb
and provide excellent documentation on how to do so. This is arguably the best way.
-
✅ Fix edge-cases for compiling
node_modules
and polish Babel 7 upgrade- Compiling
node_modules
has surfaced some issues, particularly aroundasync
/await
andregenerator
. - We also need to make sure all of our Babel configuration tricks are valid for v7.
- Compiling
-
✅ Remove
mjs
support- The ecosystem is not ready for
mjs
support and we’re going to remove support to fix complex edge cases with resolving modules. There are alternative resolve orders based on source file and supported features which are concepts Jest does not have support for yet. - This will be added back in the future.
- The ecosystem is not ready for
-
✅ Drop advanced proxy configuration and replace it with
express
middleware- Allowing users to configure their proxy in package json has been a pain-point and source of configuration, going against our values of convention.
- We will remove the ability to configure the proxy and replace it with exposing the
express
app instance. You can attach any middleware or routes to thisexpress
app that you’d like. - A recipe for proxying requests will be provided in the documentation.
-
✅ Remove support for targeting newer browsers
- We added support for targeting specific sets of browsers and there has been multiple issues that cropped up about this. We are going to remove the ability to target browsers and compile everything down to ES5 – this is in line with v1 behavior.
- The difference now is that we compile
node_modules
, so you can consume any package using newer syntax without worry. - In a follow up release, (potentially v2.1) we will explore adding a “modern”/evergreen browser mode which outputs modern, (nearly) uncompiled ESnext. This should give users the best of both worlds, and is in line with what we see in the community. A proposal going into more detail will be put together after the release of v2.
How can I help?
Please let us know your thoughts and if we missed anything. We’ll be more than happy to explain our rationale around these decisions if there’s any further questions.
If there’s anything you (and the community) feel strongly about but is not found on this list, please make an effort to send a PR! We’ll be more than happy to accept contributions.
Cheers, everyone!
Issue Analytics
- State:
- Created 5 years ago
- Reactions:193
- Comments:35 (19 by maintainers)
Top GitHub Comments
To summarize the existing changes and the above proposed changes:
v2 Features
node_modules
to support packages using newer language featuresbrowserslist
package.json keypropTypes
definitions in the production buildFeatures removed from v2
package.json
(moving tosrc/setupProxy.js
instead)mjs
extension support@Timer @gaearon You’re awesome!