Created by: andriijas
Rationale
In CRA 2.0 the user is given control to target browsers, which is a good thing. To take full advantage of browser targeting we should also put the control of polyfills in user land. Many types of apps dont need to support legacy browsers:
- company internal dashboards
- prototypes
- mobile apps
Being able to control polyfills can make the bundle slimmer for certain apps which increases performence for road warriors using mobile connections for example.
CRA has always been about making it easy to get going with React, and CRA2 will of course build upon that and make sure its still easy to learn and explore React however I recognize a theme with the upcoming 2.0 release that extends beyond that which is - getting to know the output. Many issues and PR touches this theme such as vendor chunk splitting, cdn strategies not to mention bundle analyzation tools. Lets make CRA2 a release where users can be in the front seat of the output, getting to learn it and have options to tweak it depending on the product they are building.
Knowledge sharing
By putting the polyfills in user land we also have an opportunity for interested to learn more about polyfills - why they are needed and then. I tried to document the file as good as possible - Im open for reviews and improvements.
Opt-in by default
Opt-in by default makes it as easy to get going with React as in CRA1, you need to activly think about opt-ing out and the docs probably need to be clearer about the consequence when doing so. We don't want to repeat history (#2398 (closed))
Upgrading from CRA1
Here comes the biggest challenge I guess and here more implementation is needed. We need a way to support upgraders so that they dont unintentionally breaks their browser target chain. Im reaching out for guidelines how we can solve this.
Thoughts and feedback appreciated.
Closes #3343 (closed)
PS: raf polyfill for testing intentionally removed as jsdom supports it and jest handles it.