Provide a way to configure the `mainFields` for webpack

[CarstenLeue]

The application build relies on the default webpack resolution of entry points for imported libraries, which are ["browser", "module", "main"] for a web application.

Per spec (I believe) the module entry contains the ESM5 version of the library, i.e. tree shaken but transpiled to ES5.
Some libraries, in particular those built with ng-packagr offer additional entry points, such as ESM2015 that contains a tree shaken version compiled to ES2015.

I suggest that the react scripts allow to override the desired priority order in which entry points are resolved, such that the application author can decide to consume a smaller version of a library (because it has been compiled to ES2015 instead to ES5).

In webpack this is accessible via the https://webpack.js.org/configuration/resolve/#resolvemainfields field, but this configuration is not exposed by react scripts.

[heyimalex]

Thanks for the suggestion! I don't think we're interested in supporting this at the moment; create-react-app is pretty against adding additional configuration except when it's necessary, and this is more of a performance optimization. Maybe we could add more resolutions by default if the community rallies more around a standard. I'm not very knowledgeable here though, so maybe that's already happened with ESM2015.

[CarstenLeue]

@heyimalex what is the current code generation strategy for react scripts? Will they create ES5 code or ES2015 code. In the typescript case I assume that they will use what's defined in tsconfig.json.

Would it be possible to add esm2015 to the lookup chain if tsconfig.json is already configured to generate es2015 level code? This would not require an additional configuration step and if a library does not support esm2015 nothing will break.

[heyimalex]

We use babel/preset-env and browserslist. It’s not so much that I don’t want to handle ES2015 code in node_modules (I’m pretty sure we currently do), but that I’m not sold on ESM2015 being the de-facto module entry point. For instance, I think node still hasn’t decided what their es modules entry point key is going to be. I expect some churn here soon.

It’s also just easier to punt on this than to expect packages used by our end-users to have their ESM2015 entry point properly configured, which is the problem I want to avoid; upstream lib just points ESM2015 to their non-compiled code, which has some non-standard ES2015 features (ie decorators), and then we break our user’s builds. If the ecosystem rallies around a standard, I would feel more solid pointing the finger at the misconfigured libraries (like we can for misconfigured libraries now), but until EVERYONE is opening those PRs that’s an annoying burden to put on CRA users.

I also can see the benefit, and maybe I’m overthinking it. Also I don’t speak for the whole team.

I just got really strong deja vu and I actually think this has been discussed before, so maybe we should find that issue hahaha.

[CarstenLeue]

Thanks for the explanation. I understand your conservative approach on this, once introduced it will be hard to remove it in the future if it turned out to be the wrong decision.

Standardization on the module entry points in package.json is unfortunately non existent, except for the main entry (afaik). Even the module entry is not well defined other than it using ES module syntax. I could e.g. not find any reliable information that it has to be ES5 code with ESM import style.

A sort of de-facto standard I am aware of is the Angular Package Format (https://goo.gl/jB3GVv). Despite having been defined by the competition, this is a concise spec and library generation is also well supported by tools such as ng-packagr (the later can also be used to create react projects without any remaining reference to Angular, despite the naming).

So I think it would be a good step to align with APF.

@CarstenLeue at the end of the README it says that if you need more customization you have alternatives. It seems very outdated.
Did you try CRACO?
https://github.com/gsoft-inc/craco