es5 polyfills core-js is missing

[dantman]

Does core-js intend to fully polyfill es5 so it can replace es5-{shim,sham}? I see that core-js polyfils parts of es5 but not others that es5-shim does.

Some es5 polyfills I see missing in core-js:

• parse{Int,Float} (should ignore leading zeros without needing an explicit parseInt(*, 10)
• Date.parse ISO parsing
• changes to Number#toFixed and related methods

It also forces the polyfill on some things like String#lastIndexOf and Array#lastIndexOf and String#split when a browser exhibits a certain bug.

There are probably more es5-shim polyfills that core-js are missing than is on my list. But if someone really wants to compare polyfill quality and bring core-js to the same level. Then theoretically, running es5-shim's test suite on core-js in an es3 environment would tell you exactly that.

---

The parseInt change is rather curious. According to compatibility table Chrome 7-22 supports most parts of es5 including Object.create, Object.defineProperty, and Object.freeze but does not implement es5 parseInt. So what is essentially a browser with most of es5 needs this polyfill.

[zloirock]

It's a very good issue, I have been waiting for it for a long time. Now I really want to sleep, tomorrow I will explain the situation.

[zloirock]

Instead of ES6 or ES7 parts of core-js, ES5 does not contain all possible fixes. Initially, it was only basic polyfills for support IE6-8, PhantomJS 1.9 and early ES5 implementations. I thought these engines will die in near time and it can be removed, for example, in 2016. It is one of the reasons why it was not split to submodules. But IE8 will die only with Windows XP and PhantomJS 2 still not stable - this module will alive for a long time. I just forgot (did not want to remember because nobody resembled) about many other fixes by the ES5 spec for a long time. For modern engines too.

Sure, I will add missed ES5 polyfills, but not for very obsolete, only for supported engines.

However, there is a problem. Many people just use core-js/es6, babel-runtime also does not add core-js/es5 - fixes for modern browsers just will not be added. Maybe makes sense join ES5 and ES6 namespaces. Caps for most ES5 Object methods and String#trim already joined with ES6 fixes. In near time, the same will be with Array methods (ToLength and @@species fixes), etc. So, in core-js, for ECMAScript, we will have only 2 main namespaces - for the stable spec and for proposals. Sure, in a major release after some month. Need to think about it.

[dantman]

Thanks for replying @zloirock

I am kind of dismayed about how long Chrome went essentially with es5 support (at least enough for core-js to work with iirc) but without fixing parseInt. But you are right, the browser stats for these versions are almost nothing. Someone jumping on an old computer that hasn't started up and updated Chrome yet isn't something to really worry about.

I wouldn't necessarily worry about moving the es5 polyfills into es6. Aside from toISOString I don't really see any parts of the es5 polyfill trying to fix bugs in es5 implementations. Most of the module is polyfilling the "easy" stuff that's already supported in most levels of es5 implementations. Which isn't really necessary as core-js/es5 isn't complete enough for es3 but these polyfills are unnecessary in most es5 environments.

I think it might be best that if someone wants to polyfill an es3 environment like IE8 or obsolete Chrome we should just direct them to use es5-{shim,sham} instead of the es5 portion of core-js. Then use core-js for everything es6+.

[zloirock]

Most of the required polyfills added and will be available in 2.1. Date constructor and Date.parse will be added little late with ES6+ fixes (#63), some other polyfills too.