Polyfills should be a build step only

[marklundin]

Polyfills should be a build step only

[mvaligursky]

Perhaps we should only add them when building ES5 targets, but not when building ESM?

[marklundin]

Perhaps we should only add them when building ES5 targets, but not when building ESM?

We also don't include a polyfill for Object.entries() which is partially responsible for #6011. So including it as part of the build would catch whenever we introduced a new language feature an polyfill for it

[marklundin]

For now though, you're probably right @mvaligursky, we can just add a conditional flag that omits from the ES6 build

[slimbuck]

Wouldn't it be easier to change the engine compile process to translate output ESM build to UMD and have that step add the polyfills?

[marklundin]

core-js does this. However some initial tests show it's quite aggressive. For example including new Float32Array() adds polyfills for all methods, even those methods are never called. I imagine this is by design (maybe some of the polyfills depend on each other), but as our build UMD target is pretty old, core-js is adding around 160Kb of code, just for TypedArray.

Auto-polyfilling definitely seems like the right way to go, but it needs some more investigation and optimisation. Either way, as #6011 shows, we don't have a polyfill for Object.entries, which is used in a few places, so the current UMD build has not worked with those code paths on pre Chrome 54 era browsers.

[mvaligursky]

Considering we're hoping to deprecate the IMD build in no too distant future, we might just add that single polyfill missing at the moment and call it a day for now.

[marklundin]

I think that's fine for now, we just exclude these in the ES6 build