Add a new polyfill
About 2 min
Add a new polyfill
- The polyfill implementation should be added to the
packages/core-js/modules
directory. - Shared helpers should be added to the
packages/core-js/internals
directory. Reuse already existing helpers. - For export the polyfill, in all common cases use
internals/export
helper. Use something else only if this helper is not applicable - for example, if you want to polyfill accessors. - If the code of the pure version implementation should significantly differ from the global version (that's not a frequent situation, in most cases
internals/is-pure
is enough), you can add it topackages/core-js-pure/override
directory. The rest parts ofcore-js-pure
will be copied fromcore-js
package. - Add the feature detection of the polyfill to
tests/compat/tests.js
, add the compatibility data topackages/core-js-compat/src/data.mjs
, how to do it see here, and the name of the polyfill module topackages/core-js-compat/src/modules-by-versions.mjs
(this data is also used for getting the default list of polyfills at bundling and generation indexes). - Add it to entry points of those directories where it's required:
- Add unit tests to
tests/unit-global
andtests/unit-pure
. - Add tests of entry points to
tests/entries/unit.mjs
. - Make sure that you are following our coding style.
- Document it in README.md, CHANGELOG.md and docs
Style and standards
The coding style should follow our ESlint configuration. You can test it by calling npm run lint
. Different places have different syntax and standard library limitations:
- Polyfill implementations should use only ES3 syntax and standard library, they should not use other polyfills from the global scope.
- Unit tests should use the modern syntax with our minimalistic Babel config. Unit tests for the pure version should not use any modern standard library features.
- Tools, scripts and tests, performed in NodeJS, should use only the syntax and the standard library available in NodeJS 8.
File names should be in the kebab-case. Name of polyfill modules should follow the naming convention namespace.subnamespace-where-required.feature-name
, for example, esnext.set.intersection
. The top-level namespace should be es
for stable ECMAScript features, esnext
for ECMAScript proposals and web
for other web standards.