Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

differential loading of additional (!) polyfills #14168

manfredsteyer opened this Issue Apr 15, 2019 · 2 comments


None yet
3 participants
Copy link

manfredsteyer commented Apr 15, 2019

馃殌 Feature request

Command (mark with an x)

- [ ] new
- [ x ] build
- [ x ] serve
- [ x ] test
- [ x ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc


Currently, there is no way to define custom polyfills that are only loaded for ES5 or ES2015+ browsers. While the polyfills for ES5 browsers are added automatically since some minor versions, we cannot influence them. This is, however, important when using web components b/c in this case we need to load polyfills for ES5 browsers and shims for ES2015+. The latter one is required for ES2015+ browsers if we don't use differential loading and downlevel to ES5. This feature request proposes a solution.

Describe the solution you'd like

While it's not the most known feature, we can already define that scripts go into specific additional bundles. The following extra-polyfills script would be put into a bundle extra.js

    "input": "src/extra-polyfills.ts",
    "bundleName": "extra"

This proposal would just add a type property telling the CLI for which browsers the bundle is intented:

    "input": "src/extra-polyfill.ts",
    "bundleName": "extra",
    "type": "module"

For the time being, we could go with three values: all (all browsers), module (ES2015+ browsers), and nomodule (ES5 browsers).

If we extend the possibilities of differential loading we could use this type property to point to more fine-grained information according to the srcset property.

This approach also solves the problem that specific polyfills have to be loaded in a specific order. E. g. the web component polyfills need to be loaded after the ES5 polyfills (core.js, etc.)

Describe alternatives you've considered

ng new could generate own polyfill files like polyfills-es2015.ts and polyfills-es5.ts and point to it with specific properties in angular.json. However, this is more intrusive, leads to confusion esp. if not needed and is less flexible.


This comment has been minimized.

Copy link

alan-agius4 commented Apr 15, 2019

This approach also solves the problem that specific polyfills have to be loaded in a specific order.

Is there a problem that we are not aware of? The order of polyfills should be retained already.

Also potentially, following differential loading, we can make certain polyfills added based on the known browser features and the features that the app needs. Using browserlist and caniuse.

Also, note that at the moment, there is already a polyfills option in angular.json


This comment has been minimized.

Copy link
Contributor Author

manfredsteyer commented Apr 15, 2019

Regarding the order: If we put the additional polyfills to the end of the es5-polyfills this issue would also be solved. Currently, however, we cannot influence the es5-polyfills from the outside.

The browser list idea is a really nice one. In this case, we need a mapping b/w polyfills and caniuse features. This way, we can answer the question "do we need this polyfill at all"? But it doesn't answer the question "do we have to load this polyfill now". To answer this question, we need to know whether the polyfill is needed for module- or nomodule-browsers. Of course, we could infer this by joining (in the sense of a relational DB) module/nomodule browsers with browsers supporting web components. On the other side, this is more difficult and I'm not sure if it is needed.

When it comes to web component polyfills the rule of tumb "an es5 browser needs the polyfill; an es2015+ browser does not" will be a safe and simple assumption once edge is using chromium.

@ngbot ngbot bot modified the milestones: Backlog, needsTriage Apr 18, 2019

@ngbot ngbot bot modified the milestones: needsTriage, Backlog Apr 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.