Support new proposals corejs3 polyfills #99

JLHwung · 2021-08-24T21:50:19Z

In this PR we add all proposals currently supported in core-js@3.18.0.

~~This PR includes commits from #98, I will rebase when that one gets merged.~~

zloirock · 2021-08-25T01:06:05Z

packages/babel-plugin-polyfill-corejs3/src/built-in-definitions.js

@@ -483,6 +515,10 @@ export const StaticProperties: ObjectMap<
 };

 export const InstanceProperties = {
+  asIndexedPairs: define("instance/asIndexedPairs", [
+    "esnext.async-iterator.as-indexed-pairs",
+    "esnext.iterator.as-indexed-pairs",


The most core-js modules have dependencies. Check related core-js entry points like this https://github.com/zloirock/core-js/blob/master/packages/core-js/features/async-iterator/as-indexed-pairs.js.

zloirock · 2021-08-25T01:09:22Z

It seems that shipped-proposals.js also should be updated.

packages/babel-plugin-polyfill-corejs3/src/built-in-definitions.js

zloirock · 2021-08-26T20:10:48Z

packages/babel-plugin-polyfill-corejs3/src/built-in-definitions.js

+
+const IteratorDependencies = [
+  "esnext.iterator.constructor",
+  ...CommonIteratorsWithTag,


Common iterators are required only for (Async)Iterator.from, not for other methods from this proposal. Also, you didn't add (Async)IteratorDependencies to some methods.

you didn't add (Async)IteratorDependencies to some methods.

Yeah I should have explained that. Some (Async)IteratorDependencies are not added because the plugin currently does not support dependencies of conditional dependencies. If we add (Async)IteratorDependencies to .map because of esnext.array-iterator.map, users of es.array.map will find es.promise imported even though they do not enable proposals: true, which will be very confusing.

We can add back these dependencies when the provider support this feature.

However, those (async)iterators methods will not work without those dependencies. I solved it before by moving instance dependencies to constructors, the thread below, but in this case, we can't do it.

However, those (async)iterators methods will not work without those dependencies.

In that case I lean to remove these features (not for take which does not share name with stable features) and reland them after we support sub dependencies, otherwise it unnecessarily bloat the generated code, assuming most users only use stable features.

It will work in combination with other features that have those dependencies, so it's better to leave them for work at least somehow.

zloirock · 2021-08-26T20:14:07Z

packages/babel-plugin-polyfill-corejs3/src/built-in-definitions.js

@@ -573,6 +705,10 @@ export const InstanceProperties = {
  trimLeft: define("instance/trim-left", ["es.string.trim-start"]),
  trimRight: define("instance/trim-right", ["es.string.trim-end"]),
  trimStart: define("instance/trim-start", ["es.string.trim-start"]),
+  uniqueBy: define("instance/unique-by", [
+    "esnext.array.unique-by",
+    "esnext.typed-array.unique-by",


You forgot to remove esnext.typed-array.* and *.emplace from instance properties dependencies after moving them to constructors dependencies.

I don't follow why they should be removed from instance properties. The constructor dependencies are only used in builtins such as Float32Array via typed helper. If we remove them from instance properties, we can't polyfill usages where the constructor does not present:

function (typeArray) { return typeArray.uniqueBy(x => x%2) }

Before passing to those functions, typeArray should be created and most likely via typed arrays constructors that have those dependencies. It was moved to constructors dependencies by the reason that you wrote here #99 (comment)

Also, uniqueBy depends on es.map.

Also, uniqueBy depends on es.map.

Another use case for sub dependencies. And if we remove esnext.array.unique-by here, we lost the knowledge that es.map is required for .uniqueBy because of an esnext features which should only be enabled behind proposals: true.

Or we may deliberately use the esnext.* alias for stable features (if they will be supported in corejs3), so we trick the plugin to consider esnext.map a proposal feature and don't pull esnext.map for .uniqueBy when proposals are not enabled.

And if we remove esnext.array.unique-by here, we lost the knowledge that es.map is required for .uniqueBy because of an esnext features which should only be enabled behind proposals: true.

I'm not sure that I understood what you mean.

Yes, only es.map will be added without proposals: true on .uniqueBy. But .uniqueBy is not too common property name. es.map should be added only on .uniqueBy instance property, so it will not pollute the bundle only with typed array creation.

packages/babel-plugin-polyfill-corejs3/src/built-in-definitions.js

zloirock

Missed definitions for Annex B features:

es.date.get-year
es.date.set-year
es.date.to-gmt-string
es.escape
es.string.substr
es.unescape

They are required at first for non-browser engines and IE8-.

Missed es.reflect.to-string-tag that should be added to the global Reflect dependency (+ es.object.to-string).

JLHwung · 2021-08-27T14:49:38Z

I didn't add annex B features because they are not recommended for general usage and no one ever complains about that. es.string.substr should be added though.

zloirock · 2021-08-27T15:11:29Z

It's at first for legacy code - it's why they are in Annex B, but not removed from the spec.

zloirock · 2021-08-27T15:28:48Z

Missed es.regexp.test (with es.regexp.exec dependency).

zloirock · 2021-08-30T17:39:15Z

Left:

es.date.get-year
es.date.set-year
es.date.to-gmt-string
es.escape
es.unescape

es.reflect.to-string-tag

and updating of shipped-proposals.js.

JLHwung · 2021-08-30T20:10:55Z

I tend to defer the annex-b support. Other review comments are resolved.

zloirock · 2021-08-31T00:26:15Z

I insist on adding Annex B features at least for consistency with many other already added Annex B features. At least to the global version. Anyway, they will not be added if targets are configured properly and they are not required. If you use a legacy library that uses escape / unescape in an embed JS engine or .getYear in IE8, they should work as expected.

packages/babel-plugin-polyfill-corejs3/src/built-in-definitions.js

zloirock · 2021-09-01T17:22:43Z

Please, update core-js-compat to 3.17.0.

tc39/ecma262#2057

They are supported in constructor dependencies

packages/babel-plugin-polyfill-corejs3/test/check-builtin-definitions.test.js

…nitions.test.js

JLHwung added the enhancement New feature or request label Aug 24, 2021