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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caching and non-frozen arrays #75

Open
jridgewell opened this issue Nov 18, 2022 · 47 comments
Open

Caching and non-frozen arrays #75

jridgewell opened this issue Nov 18, 2022 · 47 comments

Comments

@jridgewell
Copy link
Member

    > This was a request from @ljharb. I can update the algorithm to iterate code points?

I suppose that works too, though I'd regard it as overkill vs my suggestion.

I decided to just key using the raw property.

In #73 you're keying by the result of DedentStringsArray, which doesn't work because that's a spec-internal List, not an object:

1. Let _raw_ be ? DedentStringsArray(? Get(_t_, *"raw"*)).
1. For each element _e_ of the _dedentMap_, do
  1. If _e_.[[Raw]] is not ~empty~ and SameValue(_e_.[[Raw]], _raw_) is *true*, return _e_.[[Dedented]].

Presumably you meant something like

1. Let _rawProp_ be ? Get(_t_, *"raw"*).
1. For each element _e_ of the _dedentMap_, do
  1. If _e_.[[Raw]] is not ~empty~ and SameValue(_e_.[[Raw]], _rawProp_) is *true*, return _e_.[[Dedented]].
1. Let _raw_ be ? DedentStringsArray(_rawProp_).

That would be an improvement, but still runs into weirdness like:

let x = { raw: ['a'] };
console.log(String.dedent(x)); // 'a', as expected
x.raw[0] = 'b';
console.log(String.dedent(x)); // 'a' - ???

I think you also want to include an IsFrozen check on arg.raw before using the registry at all. That is

1. Let _rawProp_ be ? DedentStringsArray(? Get(_t_, *"raw"*)).
1. If _rawProp_ is not an Object, throw a *TypeError* exception.
1. Let _isFrozen_ be ? TestIntegrityLevel(_rawProp_, ~frozen~).
1. If _isFrozen_ is *true*, then
  1. For each element _e_ of the _dedentMap_, do
    1. If _e_.[[Raw]] is not ~empty~ and SameValue(_e_.[[Raw]], _rawProp_) is *true*, return _e_.[[Dedented]].
1. Let _raw_ be ? DedentStringsArray(_rawProp_).

(You can additionally add a check before doing the lookup in the registry, but it's technically redundant - things can't go from frozen to un-frozen, so if an object isn't frozen it can't be in the registry and the lookup will not find anything.)

I've written this to throw if .raw is not an Object, though if you really want to support primitives you could do

1. If _rawProp_ is not an object, let _isFrozen_ be *true*.
1. Else, let _isFrozen_ be ? TestIntegrityLevel(_rawProp_, ~frozen~).

instead. Though I note that the definition of [[DedentMap]] says it is keyed by objects, so you probably do want the throw.

Originally posted by @bakkot in #72 (comment)

@Josh-Cena
Copy link
Contributor

Could this get some help from array-is-template-object? (Although that proposal seems to not have progressed much...) TestIntegrityLevel invokes too many observable behaviors ([[IsExtensible]] + [[OwnPropertyKeys]] + [[GetOwnProperty]]), while I don't feel like const obj = { raw: Object.freeze(["foo"]) }; String.dedent(tag)(obj) just for the sake of caching is hugely useful. (I don't think people anticipate identity if the tag call is not via a template literal anyway.)

@bakkot
Copy link
Contributor

bakkot commented Nov 20, 2022

Could this get some help from array-is-template-object?

Technically yes, but the objects it produces would not count as template objects, which means they wouldn't be cached by other mechanisms similar to this one. Which seems bad - you want stuff to compose.

TestIntegrityLevel invokes too many observable behaviors

Eh, 99%+ of the time it's going to be either "it's not extensible because it's an ordinary object" or "it's frozen because it's a template object", both of which are very cheap to check, so it's not like that's actually going to slow anything down in engines except for the Proxy case, which is slow anyway.

@Josh-Cena
Copy link
Contributor

Josh-Cena commented Nov 20, 2022

the objects it produces would not count as template objects

I'm surprised—you mean if you do:

String.dedent(Array.isTemplateObject)`
  foo
`;

The result is expected to be false, even when Array.isTemplateObject ships?

so it's not like that's actually going to slow anything down

That's fair, but the point is that it could be always one internal slot lookup, unless people actually expect the semantic that a frozen raw property behaves exactly like a template array. When I said that, I was actually not thinking about performance, only about what people can observe if they do pass a proxy.

Another point is documentation. Speaking as an MDN writer, I feel more comfortable explaining "String.dedent caches only if you use it as a template tag; calling it as a function doesn't cache" than "String.dedent caches only if it has a frozen raw property", because that sounds like a leak of implementation (i.e. that String.dedent dedents the raw array and cooks it instead of dedenting the cooked array).

I do see that this proposal is seeking stage 3 soon, in which case testing frozeness is still a reasonable solution so as not to be blocked by the other proposal.

@bakkot
Copy link
Contributor

bakkot commented Nov 20, 2022

The result is expected to be false, even when Array.isTemplateObject ships?

Yes. If Array.isTemplateObject ships, it will only return true for objects which correspond to literal source text template objects, not anything derived from them, even things derived via built-ins.

When I said that, I was actually not thinking about performance, only about what people can observe if they do pass a proxy.

Eh, I think we shouldn't be worrying too much about what traps people will observe if they pass a Proxy. That's an extremely unusual case, and not worth spending a lot of effort designing around. Generally speaking I think we should pick a design which makes sense for the common case, and only modify it when considering Proxies if their existence is going to make it impossible to do efficiently at baseline tier in the common case - which is often the case, but isn't the case here.

Another point is documentation. Speaking as an MDN writer, I feel more comfortable explaining "String.dedent caches only if you use it as a template tag; calling it as a function doesn't cache" than "String.dedent caches only if it has a frozen raw property", because that sounds like a leak of implementation (i.e. that String.dedent dedents the raw array and cooks it instead of dedenting the cooked array).

Well, the fact that it dedents based on the raw array is relevant anyway if you're talking about invoking it as a function directly (and not as a wrapper on another tag), because in that case you have to pass { raw: stuff }, not stuff. And if you're talking about invoking it as a function directly, I don't think there's anything wrong with saying "it caches if the raw array is frozen, like it is for template literals".

@Josh-Cena
Copy link
Contributor

Oh well, I get the reasoning. In this case testing for frozeness sounds like the best behavior.

About Array.isTemplateObject though, this makes me wonder if a syntax is the best solution for dedent. (I understand TC39 doesn't like that.) Otherwise it's really surprising if a "secure" tag can only work without dedenting.

@bakkot
Copy link
Contributor

bakkot commented Nov 20, 2022

Otherwise it's really surprising if a "secure" tag can only work without dedenting.

I have the opposite opinion - it would be surprising if a security feature passed for anything other than the literal text in your program. Even if we did have syntax for String.dedent I don't think we'd want Array.isTemplateObject to pass for things derived from that syntax. You really, really want a feature like isTemplateObject to be as straightforward as possible, not for it to try to get clever and accept things other than the maximally raw input. Interaction of features like that is one of the more common ways to end up with vulnerabilities.

@Josh-Cena
Copy link
Contributor

Josh-Cena commented Nov 20, 2022

This is digressing a bit, but in a hypothetical world where dedent uses a sigil, you would probably expect the tag it encloses to receive an actual template array. It's only because String.dedent is a function that we have this function vs. template tag dichotomy.

@bakkot
Copy link
Contributor

bakkot commented Nov 20, 2022

This is digressing a bit, but in a hypothetical world where dedent uses a sigil, you would probably expect the tag it encloses to receive an actual template array.

Not in terms of Array.isTemplateObject, no. That's what I'm saying. Array.isTemplateObject should only ever return true for things which are literal source text in your program, not for things derived from that, even things derived via built-in syntax or APIs.

@Josh-Cena
Copy link
Contributor

Hmmm, I see. I need to reread the motivation of that proposal.

@hax
Copy link
Member

hax commented Nov 30, 2022

@Josh-Cena As I understand array-is-template-object is for security check, so not fit for this case.

@rbuckton
Copy link

rbuckton commented Nov 30, 2022

During the plenary today there was a discussion about this issue and whether String.dedent should throw when passed a non-template object.

I have concerns about throwing due to the potential for mixed-mode environments where you might be downleveling tagged templates but could easily still access a String.dedent that may or may not be polyfilled in that environment. If the constraint for cacheability is that "the object and the arrays must be frozen", that is something a transpiler can accomplish (at least, in ES5+). If the constraint is "the object and arrays were produced by the runtime and checked via an internal slot", then there is no way for a transpiler to meet that constraint.

@hax
Copy link
Member

hax commented Nov 30, 2022

@jridgewell Could u add comment here to explain the worst case if we use "only cache frozen" so everyone could understand the situation? Thank you.

@hax
Copy link
Member

hax commented Nov 30, 2022

Note, as the plenary discussion, we have several options:

  1. always cache (current proposal)
  2. only cache frozen
  3. cache frozen, throw if not frozen
  4. no cache

My preference is 2>1=3>>4

@jridgewell
Copy link
Member Author

For what it's worth, I consider this to be an edge case. The expectation is that this will be invoked as a real tagged template literal, and even if you have a user provided strings array, that it will not be modified (because that would break every tag function that expects immutability).

If the constraint for cacheability is that "the object and the arrays must be frozen", that is something a transpiler can accomplish (at least, in ES5+). If the constraint is "the object and arrays were produced by the runtime and checked via an internal slot", then there is no way for a transpiler to meet that constraint.

The constraint would be "frozen", not "internal slot".

Could u add comment here to explain the worst case if we use "only cache frozen" so everyone could understand the situation

The issue is silently doing the wrong behavior. Tagged template literals are expected to receive a consistent object identity, and using String.dedent must not break that expectation. Any kind of behavior could be built upon the expectation that "I'll only do this once per tagged template".

The cases that I'm most familiar with is for DOM rendering. With this, the most obvious negative side-effect is that the performance will be bad (the DOM would be wiped out because we're rendering a "new" template). But it also effects user state (text written in an input, focus state, etc). Silently doing incorrect behaviors that look like they're working correctly are the worst kinds of bugs to fix, because the bug isn't obvious.

At least with the current cache everything behavior, the bug is obvious. You'll see some incorrect value when you render, and it'll be possible to track the bug back to String.dedent. Maybe the fix won't be obvious (don't mutate the array), but the there'll be a known place to start searching.

@brad4d
Copy link

brad4d commented Nov 30, 2022

If I were using String.dedent with a mutable array, I would definitely expect it to use the values the array currently has. The caching is an implementation detail I likely wouldn't even know about.

If I get a thrown exception saying the array must be frozen, I immediately know how to deal with that.
If I get incorrect output only sometimes (when the array has been modified, which likely doesn't always happen), it may take a long time for me to notice the problem and even longer to figure out why. And, when I figure out why, I will likely think that String.dedent is misbehaving.

So, I believe throwing an exception for an unfrozen array is the most user friendly choice.

Well, actually, I think just letting it be slow (no caching) for an unfrozen array is the most user friendly, but it seems others disagree on that point.

@jridgewell
Copy link
Member Author

jridgewell commented Nov 30, 2022

with a mutable array, I would definitely expect it to use the values the array currently has. The caching is an implementation detail I likely wouldn't even know about.

This breaks with the expectation of every tag function I've seen. Caching is done cheaply on the array identity using a WeakMap, and if you modify it, you're gonna still get the cached results. I don't think String.dedent is special here.

@bakkot
Copy link
Contributor

bakkot commented Nov 30, 2022

Among

  1. always cache (current proposal)
  2. only cache frozen
  3. cache frozen, throw if not frozen
  4. no cache

My preference ordering is 2>1>3>>4, but the difference between 1 and 3 is not large for me (and anything except 4 would be acceptable). The downside of 3 is just that when using it manually you have to Object.freeze(), which is a little annoying but at least you'll get an error.

@hax
Copy link
Member

hax commented Nov 30, 2022

The reason I don't like "always cache" is String.raw do not have such behavior.

About DOM rendering, I suppose we are talking code like:

String.dedent(html)`
   <div>...</div>
`

The point here is html tag functions rely on frozen semantic, and we are worrying Babel loose mode compile the code like String.dedent({raw: ["<div>...</div>", ""]}), not String.dedent({raw: Object.freeze(["<div>...</div>", ""])})

Personally I feel this is the edge case, and mainly a toolchain issue. So can we have a compromised solution like:

  1. use 2 (only cache frozen) for String.dedent(array, ...subs), use 3 or 1 semantic for String.dedent(func) ?

@jridgewell
Copy link
Member Author

  1. always cache (current proposal)
  2. only cache frozen
  3. cache frozen, throw if not frozen
  4. no cache

My ordering here would be 1=3>2 (and I will reject 4 entirely)

@gibson042
Copy link

At least with the current cache everything behavior, the bug is obvious. You'll see some incorrect value when you render, and it'll be possible to track the bug back to String.dedent. Maybe the fix won't be obvious (don't mutate the array), but the there'll be a known place to start searching.

@jridgewell Except if you don't see the incorrect value because you overlooked it. I would definitely include propagating array mutation at a distance in the category of "silently doing incorrect behaviors that look like they're working correctly".

The caching is an implementation detail I likely wouldn't even know about… If I get a thrown exception saying the array must be frozen, I immediately know how to deal with that. If I get incorrect output only sometimes (when the array has been modified, which likely doesn't always happen), it may take a long time for me to notice the problem and even longer to figure out why.

@brad4d Exactly. 👍

@bakkot
Copy link
Contributor

bakkot commented Nov 30, 2022

So, while it's not my first choice, it sounds like "cache frozen, throw if not frozen" is acceptable to everyone?

@hax
Copy link
Member

hax commented Nov 30, 2022

This breaks with the expectation of every tag function I've seen.

@jridgewell To be honest, I don't see many tag function (except DOM parsing) expect that (and do cache), for example, it seems no userland dedent util functions (which mentioned in the readme) do cache. 😅

@jridgewell
Copy link
Member Author

The reason I don't like "always cache" is String.raw do not have such behavior.

String.raw and String.cooked don't perform any caching. Not doing it doesn't matter much, since they're the final step (they don't wrap other tag functions). But String.dedent needs caching behavior, because the tags we wrap will expect it.

If I get incorrect output only sometimes (when the array has been modified, which likely doesn't always happen), it may take a long time for me to notice the problem and even longer to figure out why.

Exactly

String.dedent won't be the only tag function that breaks with this, every one that does caching uses weakmap.get(array) to do this. I think this is such a niche edge-case, I've never seen anyone try to modify a template strings arrray.

So, while it's not my first choice, it sounds like "cache frozen, throw if not frozen" is acceptable to everyone?

That would be ok with me.

for example, it seems no userland dedent util functions (which mentioned in the readme) do cache.

No dedent function wraps other tag functions. We need caching because those wrapped functions will expect consistent object identity.

@hax
Copy link
Member

hax commented Nov 30, 2022

Update options:

  1. always cache (current proposal)
  2. only cache frozen
  3. cache frozen, throw if not frozen
  4. no cache
  5. use 2 or 4 (should have no observable diff) for String.dedent(obj, ...subs), use 3 or 1 semantic for String.dedent(func)

I add the extra option 5, because normally direct usage of String.dedent do not have big concern, only wrapped tag functions have such concern.

@ljharb
Copy link
Member

ljharb commented Nov 30, 2022

fwiw my preference is 2, 1, 3, 4. caching is a performance optimization, and "not caching" isn't breakage, it's just slowdown - if it is breakage, it's not actually a cache, it's something else.

@bakkot
Copy link
Contributor

bakkot commented Nov 30, 2022

@hax I don't really like your option 5 because it means that String.dedent(Sting.cooked)(obj) would be different from String.dedent(obj). I'd prefer to do the same thing in both cases, I think; the benefits of making them different are less than the costs of making it more complicated.

@hax
Copy link
Member

hax commented Nov 30, 2022

String.raw and String.cooked don't perform any caching. Not doing it doesn't matter much, since they're the final step (they don't wrap other tag functions). But String.dedent needs caching behavior, because the tags we wrap will expect it.

I think this is why I feel uncomfortable with "always cache", because String.dedent also could be the final step (just like the example in the slide). And if it's the final step, "caching" is just a implementation details.

@hax
Copy link
Member

hax commented Nov 30, 2022

@bakkot Yeah, the option 5 is a trade-off so it lose some nature. But I think it still a good option.

There is no real harm that String.dedent(tag) not behave same as tag (because String.dedent(tag) give u a wrapped func, it supposed to modify behavior). On the other side, option 1 and 3 really introduce different behavior between String.dedent and String.raw on unfrozen obj.

@jridgewell
Copy link
Member Author

Can we agree then on the throwing solution?

@Josh-Cena
Copy link
Contributor

What's the benefit of throwing compared to not caching at all? If I pass a custom object that pretends to be a template, I wouldn't really expect anything to be cached anyway (even with a wrapped tag). This just makes dedenting dynamic strings harder: if I can't do String.dedent(str), I can live with String.dedent({ raw: [str] }), but now I have to do String.dedent({ raw: Object.freeze([str]) }).

@jridgewell
Copy link
Member Author

If I pass a custom object that pretends to be a template, I wouldn't really expect anything to be cached anyway (even with a wrapped tag).

I think #75 (comment) answers that. Silently doing something expensive when we know it's incorrect is extremely difficult to debug. At least loudly throwing will help the dev fix the issue.

@Josh-Cena
Copy link
Contributor

Josh-Cena commented Nov 30, 2022

The expectation, IMO, is that template literals are cached and not recomputed. Template literals mean that the string literals always have stable values, and these stable values are trivially inlined in the source code, so the mental burden is really low. This is not the case with an ad hoc object. It's almost the exact opposite semantic—the template object { raw: [str] } is expected to change, either because I used a different value as str, or because I mutated the array.

My concern is "help fix the issue" where the issue is really a non-issue—if I go to the trouble of creating an ad hoc object just to trick String.dedent, why would I expect it to magically cache anything anyway? I would strongly prefer the non-wrapping version to not throw at the minimum; but even for the wrapping version, unless there's some userland library that also throws for non-frozen template objects, I don't think we are preventing anything that's not possible under the status quo.

@jridgewell
Copy link
Member Author

It's common for transformers to turn tagged template literals into unfrozen arrays, so it's not really possible to determine what's literal source code or dynamically generated arrays.

I think the expectation that anyone is going to mutate an array and call a tag function is really the non-issue, though. Who does that? Again, every tag function that I've seen that does caching, does it by using the array's identity. This is just the normal practice.

@ljharb
Copy link
Member

ljharb commented Nov 30, 2022

What's incorrect about doing something expensive, if it produces the same result?

@jridgewell
Copy link
Member Author

Lit operates a bit like container.innerHTML = someHTML. When rendering the same template, the diffing is fast, yes. But it also preserves user state that cannot be represented in HTML, like focus state, input values, toggle state. It's not just performance, and it'll be difficult to isolate.

@ljharb
Copy link
Member

ljharb commented Nov 30, 2022

ah ok, so you're using the identity of the template array to distinguish individual components, and thus individual bags of state?

@jridgewell
Copy link
Member Author

The state is maintained by the browser itself, we're using the array's identity to determine if this is a new template. If it's the same template, we can just do basic DOM diffing on the dynamic expressions in the template. If it's a new template, the old tree is completely removed and the new tree is inserted. Not maintaining the array's identity causes lit to completely wipe out the DOM state during every render.

@Josh-Cena
Copy link
Contributor

Josh-Cena commented Nov 30, 2022

So, IIUC, there's only an observable difference in the case where (a) you are passing a dynamic object (b) you are wrapping another tag. In this case we need to compare it against the world where a dynamic object is directly passed to the said tag—and by mimicking their behavior, we would introduce no degradation of experience, to say the least. If they always cache, it means mutating the array is not going to work anyway, and we are fine to also cache. And I don't really think they throw for non-frozen objects, do they?

@jridgewell
Copy link
Member Author

Every tag I've seen uses a WeakMap on the array identity, if they cache. I've never seen one throw for an unfrozen array.

@ljharb
Copy link
Member

ljharb commented Nov 30, 2022

I wonder if things like Lit could do a check on the array like "if the array is frozen, use its identity, else serialize a shallow comparison to a memoized identity"? or would that be prohibitive in userland

@Josh-Cena
Copy link
Contributor

I prefer non-wrapping dedent calls to not throw for non-frozen objects (and probably not cache either, so that mutations work as expected), but I don't have strong opinions about wrapping calls. This makes me look at option 5.

String.dedent(String.cooked)(obj) would be different from String.dedent(obj).

This is the only argument I see against option 5 (apologies if I missed any). But IMO throwing an error for the former case does not constitute an unexpected behavior difference—"throws if called with another tag and then passed with a non-frozen object" sounds like a reasonable invariant.

@jridgewell
Copy link
Member Author

or would that be prohibitive in userland

String equality on large strings gets to be kinda expensive. Again, this is a super edge case, it's not expected that you ever mutate the input template strings array.

@jridgewell
Copy link
Member Author

I check the various transformers:

It's the TS one that worries me. I don't even know how to configure it to output a frozen template strings array. I really think we should continue with either the current semantics, or go the throwing semantics. But the uncached semantics seems like the wrong choice.

@rbuckton
Copy link

rbuckton commented Dec 1, 2022

I'm sure we can change TS to freeze the generated template object if that's necessary.

@ljharb
Copy link
Member

ljharb commented Dec 1, 2022

That should likely be done anyways, I’d hope.

@jridgewell
Copy link
Member Author

Yah, I agree that TS should update to freeze, but it also requires devs to update to get the correct behavior.

@rbuckton
Copy link

rbuckton commented Dec 6, 2022

Yah, I agree that TS should update to freeze, but it also requires devs to update to get the correct behavior.

It depends. We could implement the freeze-behavior in the __makeTemplateObject helper. Anyone using --importHelpers could potentially get this for free if we patch tslib. Anyone not using --importHelpers would still need to rebuild, however.

Vylpes pushed a commit to Vylpes/Droplet that referenced this issue Dec 25, 2023
This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [core-js](https://github.com/zloirock/core-js) | dependencies | minor | [`3.12.0` -> `3.34.0`](https://renovatebot.com/diffs/npm/core-js/3.12.0/3.34.0) |

---

### Release Notes

<details>
<summary>zloirock/core-js (core-js)</summary>

### [`v3.34.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3340---20231206)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.33.3...v3.34.0)

-   [`Array` grouping proposal](https://github.com/tc39/proposal-array-grouping):
    -   Methods:
        -   `Object.groupBy`
        -   `Map.groupBy`
    -   Moved to stable ES, [November 2023 TC39 meeting](https://github.com/tc39/proposal-array-grouping/issues/60)
    -   Added `es.` namespace modules, `/es/` and `/stable/` namespaces entries
-   [`Promise.withResolvers` proposal](https://github.com/tc39/proposal-promise-with-resolvers):
    -   Method:
        -   `Promise.withResolvers`
    -   Moved to stable ES, [November 2023 TC39 meeting](https://twitter.com/robpalmer2/status/1729216597623976407)
    -   Added `es.` namespace module, `/es/` and `/stable/` namespaces entries
-   Fixed a web incompatibility issue of [`Iterator` helpers proposal](https://github.com/tc39/proposal-iterator-helpers), [proposal-iterator-helpers/287](https://github.com/tc39/proposal-iterator-helpers/pull/287) and some following changes, November 2023 TC39 meeting
-   Added [`Uint8Array` to / from base64 and hex stage 2 proposal](https://github.com/tc39/proposal-arraybuffer-base64):
    -   Methods:
        -   `Uint8Array.fromBase64`
        -   `Uint8Array.fromHex`
        -   `Uint8Array.prototype.toBase64`
        -   `Uint8Array.prototype.toHex`
-   Relaxed some specific cases of [`Number.fromString`](https://github.com/tc39/proposal-number-fromstring) validation before clarification of [proposal-number-fromstring/24](https://github.com/tc39/proposal-number-fromstring/issues/24)
-   Fixed `@@&#8203;toStringTag` property descriptors on DOM collections, [#&#8203;1312](https://github.com/zloirock/core-js/issues/1312)
-   Fixed the order of arguments validation in `Array` iteration methods, [#&#8203;1313](https://github.com/zloirock/core-js/issues/1313)
-   Some minor `atob` / `btoa` improvements
-   Compat data improvements:
    -   [`Promise.withResolvers`](https://github.com/tc39/proposal-promise-with-resolvers) marked as shipped from FF121

### [`v3.33.3`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3333---20231120)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.33.2...v3.33.3)

-   Fixed an issue getting the global object on Duktape, [#&#8203;1303](https://github.com/zloirock/core-js/issues/1303)
-   Avoid sharing internal `[[DedentMap]]` from [`String.dedent` proposal](https://github.com/tc39/proposal-string-dedent) between `core-js` instances before stabilization of the proposal
-   Some internal untangling
-   Compat data improvements:
    -   Added [Deno 1.38](https://deno.com/blog/v1.38) compat data mapping
    -   [`Array.fromAsync`](https://github.com/tc39/proposal-array-from-async) marked as [supported from Deno 1.38](https://github.com/denoland/deno/pull/21048)
    -   [`Symbol.{ dispose, asyncDispose }`](https://github.com/tc39/proposal-explicit-resource-management) marked as [supported from Deno 1.38](https://github.com/denoland/deno/pull/20845)
    -   Added Opera Android 79 compat data mapping
    -   Added Oculus Quest Browser 30 compat data mapping
    -   Updated Electron 28 and 29 compat data mapping

### [`v3.33.2`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3332---20231031)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.33.1...v3.33.2)

-   Simplified `structuredClone` polyfill, avoided second tree pass in cases of transferring
-   Added support of [`SuppressedError`](https://github.com/tc39/proposal-explicit-resource-management#the-suppressederror-error) to `structuredClone` polyfill
-   Removed unspecified unnecessary `ArrayBuffer` and `DataView` dependencies of `structuredClone` lack of which could cause errors in some entries in IE10-
-   Fixed handling of fractional number part in [`Number.fromString`](https://github.com/tc39/proposal-number-fromstring)
-   Compat data improvements:
    -   [`URL.canParse`](https://url.spec.whatwg.org/#dom-url-canparse) marked as [supported from Chromium 120](https://bugs.chromium.org/p/chromium/issues/detail?id=1425839)
    -   Updated Opera Android 78 compat data mapping
    -   Added Electron 29 compat data mapping

### [`v3.33.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3331---20231020)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.33.0...v3.33.1)

-   Added one more workaround of possible error with `Symbol` polyfill on global object, [#&#8203;1289](https://github.com/zloirock/core-js/issues/1289#issuecomment-1768411444)
-   Directly specified `type: commonjs` in `package.json` of all packages to avoid potential breakage in future Node versions, see [this issue](https://github.com/nodejs/TSC/issues/1445)
-   Prevented potential issue with lack of some dependencies after automatic optimization polyfills of some methods in the pure version
-   Some minor internal fixes and optimizations
-   Compat data improvements:
    -   [`String.prototype.{ isWellFormed, toWellFormed }`](https://github.com/tc39/proposal-is-usv-string) marked as [supported from FF119](https://bugzilla.mozilla.org/show_bug.cgi?id=1850755)
    -   Added React Native 0.73 Hermes compat data, mainly fixes of [some issues](https://github.com/facebook/hermes/issues/770)
    -   Added [NodeJS 21.0 compat data mapping](https://nodejs.org/ru/blog/release/v21.0.0)

### [`v3.33.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3330---20231002)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.32.2...v3.33.0)

-   Re-introduced [`RegExp` escaping stage 2 proposal](https://github.com/tc39/proposal-regex-escaping), September 2023 TC39 meeting:
    -   Added `RegExp.escape` method with the new set of symbols for escaping
    -   Some years ago, it was presented in `core-js`, but it was removed after rejecting the old version of this proposal
-   Added [`ArrayBuffer.prototype.{ transfer, transferToFixedLength }`](https://github.com/tc39/proposal-arraybuffer-transfer) and support transferring of `ArrayBuffer`s via [`structuredClone`](https://html.spec.whatwg.org/multipage/structured-data.html#dom-structuredclone) to engines with `MessageChannel`
-   Optimized [`Math.f16round`](https://github.com/tc39/proposal-float16array) polyfill
-   Fixed [some conversion cases](https://github.com/petamoriken/float16/issues/1046) of [`Math.f16round` and `DataView.prototype.{ getFloat16, setFloat16 }`](https://github.com/tc39/proposal-float16array)
-   Fully forced polyfilling of [the TC39 `Observable` proposal](https://github.com/tc39/proposal-observable) because of incompatibility with [the new WHATWG `Observable` proposal](https://github.com/WICG/observable)
-   Added an extra workaround of errors with exotic environment objects in `Symbol` polyfill, [#&#8203;1289](https://github.com/zloirock/core-js/issues/1289)
-   Some minor fixes and stylistic changes
-   Compat data improvements:
    -   V8 unshipped [`Iterator` helpers](https://github.com/tc39/proposal-iterator-helpers) because of [some Web compatibility issues](https://github.com/tc39/proposal-iterator-helpers/issues/286)
    -   [`Promise.withResolvers`](https://github.com/tc39/proposal-promise-with-resolvers) marked as [supported from V8 ~ Chrome 119](https://chromestatus.com/feature/5810984110784512)
    -   [`Array` grouping proposal](https://github.com/tc39/proposal-array-grouping) features marked as [supported from FF119](https://bugzilla.mozilla.org/show_bug.cgi?id=1792650#c9)
    -   [`value` argument of `URLSearchParams.prototype.{ has, delete }`](https://url.spec.whatwg.org/#dom-urlsearchparams-delete) marked as properly supported from V8 ~ Chrome 118
    -   [`URL.canParse`](https://url.spec.whatwg.org/#dom-url-canparse) and [`URLSearchParams.prototype.size`](https://url.spec.whatwg.org/#dom-urlsearchparams-size) marked as [supported from Bun 1.0.2](https://github.com/oven-sh/bun/releases/tag/bun-v1.0.2)
    -   Added Deno 1.37 compat data mapping
    -   Added Electron 28 compat data mapping
    -   Added Opera Android 78 compat data mapping

### [`v3.32.2`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3322---20230907)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.32.1...v3.32.2)

-   Fixed `structuredClone` feature detection `[email protected]` bug, [#&#8203;1288](https://github.com/zloirock/core-js/issues/1288)
-   Added a workaround of old WebKit + `eval` bug, [#&#8203;1287](https://github.com/zloirock/core-js/pull/1287)
-   Compat data improvements:
    -   Added Samsung Internet 23 compat data mapping
    -   Added Quest Browser 29 compat data mapping

### [`v3.32.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3321---20230819)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.32.0...v3.32.1)

-   Fixed some cases of IEEE754 rounding, [#&#8203;1279](https://github.com/zloirock/core-js/issues/1279), thanks [**@&#8203;petamoriken**](https://github.com/petamoriken)
-   Prevented injection `process` polyfill to `core-js` via some bundlers or `esm.sh`, [#&#8203;1277](https://github.com/zloirock/core-js/issues/1277)
-   Some minor fixes and stylistic changes
-   Compat data improvements:
    -   [`Promise.withResolvers`](https://github.com/tc39/proposal-promise-with-resolvers) marked as supported [from Bun 0.7.1](https://bun.sh/blog/bun-v0.7.1#bun-ismainthread-and-promise-withresolvers)
    -   Added Opera Android 77 compat data mapping
    -   Updated Electron 27 compat data mapping

### [`v3.32.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3320---20230728)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.31.1...v3.32.0)

-   [`Array` grouping proposal](https://github.com/tc39/proposal-array-grouping), July 2023 TC39 meeting updates:
    -   [Moved back to stage 3](https://github.com/tc39/proposal-array-grouping/issues/54)
    -   Added `/actual/` namespaces entries, unconditional forced replacement changed to feature detection
-   [`Promise.withResolvers` proposal](https://github.com/tc39/proposal-promise-with-resolvers), July 2023 TC39 meeting updates:
    -   [Moved to stage 3](https://github.com/tc39/proposal-promise-with-resolvers/pull/18)
    -   Added `/actual/` namespaces entries, unconditional forced replacement changed to feature detection
-   [`Set` methods stage 3 proposal](https://github.com/tc39/proposal-set-methods), July 2023 TC39 meeting updates:
    -   Throw on negative `Set` sizes, [proposal-set-methods/88](https://github.com/tc39/proposal-set-methods/pull/88)
    -   Removed `IsCallable` check in `GetKeysIterator`, [proposal-set-methods/101](https://github.com/tc39/proposal-set-methods/pull/101)
-   [Iterator Helpers stage 3 proposal](https://github.com/tc39/proposal-iterator-helpers):
    -   Avoid creating observable `String` wrapper objects, July 2023 TC39 meeting update, [proposal-iterator-helpers/281](https://github.com/tc39/proposal-iterator-helpers/pull/281)
    -   `Iterator` is not constructible from the active function object (works as an abstract class)
-   Async explicit resource management:
    -   Moved back into [the initial proposal](https://github.com/tc39/proposal-explicit-resource-management) -> moved to stage 3, [proposal-explicit-resource-management/154](https://github.com/tc39/proposal-explicit-resource-management/pull/154)
    -   Added `/actual/` namespace entries, unconditional forced replacement changed to feature detection
    -   Ignore return value of `[@@&#8203;dispose]()` method when hint is `async-dispose`, [proposal-explicit-resource-management/180](https://github.com/tc39/proposal-explicit-resource-management/pull/180)
    -   Added ticks for empty resources, [proposal-explicit-resource-management/163](https://github.com/tc39/proposal-explicit-resource-management/pull/163)
-   Added some methods from [`Float16Array` stage 3 proposal](https://github.com/tc39/proposal-float16array):
    -   There are some reason why I don't want to add `Float16Array` right now, however, make sense to add some methods from this proposal.
    -   Methods:
        -   `Math.f16round`
        -   `DataView.prototype.getFloat16`
        -   `DataView.prototype.setFloat16`
-   Added [`DataView` get / set `Uint8Clamped` methods stage 1 proposal](https://github.com/tc39/proposal-dataview-get-set-uint8clamped):
    -   Methods:
        -   `DataView.prototype.getUint8Clamped`
        -   `DataView.prototype.setUint8Clamped`
-   Used strict mode in some missed cases, [#&#8203;1269](https://github.com/zloirock/core-js/issues/1269)
-   Fixed [a Chromium 117 bug](https://bugs.chromium.org/p/v8/issues/detail?id=14222) in `value` argument of `URLSearchParams.prototype.{ has, delete }`
-   Fixed early WebKit ~ Safari 17.0 beta `Set` methods implementation by the actual spec
-   Fixed incorrect `Symbol.{ dispose, asyncDispose }` descriptors from [NodeJS 20.4](https://github.com/nodejs/node/issues/48699) / transpilers helpers / userland code
-   Fixed forced polyfilling of some iterator helpers that should return wrapped iterator in the pure version
-   Fixed and exposed [`AsyncIteratorPrototype` `core-js/configurator` option](https://github.com/zloirock/core-js#asynciterator-helpers), [#&#8203;1268](https://github.com/zloirock/core-js/issues/1268)
-   Compat data improvements:
    -   Sync [`Iterator` helpers proposal](https://github.com/tc39/proposal-iterator-helpers) features marked as [supported](https://chromestatus.com/feature/5102502917177344) from V8 ~ Chrome 117
    -   [`Array` grouping proposal](https://github.com/tc39/proposal-array-grouping) features marked as [supported](https://chromestatus.com/feature/5714791975878656) from V8 ~ Chrome 117
    -   Mark `Symbol.{ dispose, asyncDispose }` as supported from NodeJS 20.5.0 (as mentioned above, NodeJS 20.4.0 add it, but [with incorrect descriptors](https://github.com/nodejs/node/issues/48699))
    -   Added Electron 27 compat data mapping

### [`v3.31.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3311---20230706)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.31.0...v3.31.1)

-   Fixed a `structuredClone` bug with cloning views of transferred buffers, [#&#8203;1265](https://github.com/zloirock/core-js/issues/1265)
-   Fixed the order of arguments validation in `DataView` methods
-   Allowed cloning of [`Float16Array`](https://github.com/tc39/proposal-float16array) in `structuredClone`
-   Compat data improvements:
    -   [`Set` methods proposal](https://github.com/tc39/proposal-set-methods) marked as [supported from Safari 17.0](https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes#JavaScript)
    -   New `URL` features: [`URL.canParse`](https://url.spec.whatwg.org/#dom-url-canparse), [`URLSearchParams.prototype.size`](https://url.spec.whatwg.org/#dom-urlsearchparams-size) and [`value` argument of `URLSearchParams.prototype.{ has, delete }`](https://url.spec.whatwg.org/#dom-urlsearchparams-delete) marked as [supported from Safari 17.0](https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes#Web-API)
    -   `value` argument of `URLSearchParams.prototype.{ has, delete }` marked as supported from [Deno 1.35](https://github.com/denoland/deno/pull/19654)
    -   `AggregateError` and well-formed `JSON.stringify` marked as [supported React Native 0.72 Hermes](https://reactnative.dev/blog/2023/06/21/0.72-metro-package-exports-symlinks#more-ecmascript-support-in-hermes)
    -   Added Deno 1.35 compat data mapping
    -   Added Quest Browser 28 compat data mapping
    -   Added missing NodeJS 12.16-12.22 compat data mapping
    -   Updated Opera Android 76 compat data mapping

### [`v3.31.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3310---20230612)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.30.2...v3.31.0)

-   [Well-formed unicode strings proposal](https://github.com/tc39/proposal-is-usv-string):
    -   Methods:
        -   `String.prototype.isWellFormed` method
        -   `String.prototype.toWellFormed` method
    -   Moved to stable ES, [May 2023 TC39 meeting](https://github.com/tc39/notes/blob/main/meetings/2023-05/may-15.md#well-formed-unicode-strings-for-stage-4)
    -   Added `es.` namespace modules, `/es/` and `/stable/` namespaces entries
-   [`Array` grouping proposal](https://github.com/tc39/proposal-array-grouping), [May 2023 TC39 meeting updates](https://github.com/tc39/notes/blob/main/meetings/2023-05/may-16.md#arrayprototypegroup-rename-for-web-compatibility):
    -   Because of the [web compat issue](https://github.com/tc39/proposal-array-grouping/issues/44), [moved from prototype to static methods](https://github.com/tc39/proposal-array-grouping/pull/47). Added:
        -   `Object.groupBy` method
        -   `Map.groupBy` method (with the actual semantic - with a minor difference it was present [in the collections methods stage 1 proposal](https://github.com/tc39/proposal-collection-methods))
    -   Demoted to stage 2
-   [Decorator Metadata proposal](https://github.com/tc39/proposal-decorator-metadata), [May 2023 TC39 meeting updates](https://github.com/tc39/notes/blob/main/meetings/2023-05/may-16.md#decorator-metadata-for-stage-3):
    -   Moved to stage 3
    -   Added `Function.prototype[Symbol.metadata]` (`=== null`)
    -   Added `/actual/` entries
-   [Iterator Helpers stage 3 proposal](https://github.com/tc39/proposal-iterator-helpers):
    -   Changed `Symbol.iterator` fallback from callable check to `undefined` / `null` check, [May 2023 TC39 meeting](https://github.com/tc39/notes/blob/main/meetings/2023-05/may-16.md#iterator-helpers-should-symboliterator-fallback-be-a-callable-check-or-an-undefinednull-check), [proposal-iterator-helpers/272](https://github.com/tc39/proposal-iterator-helpers/pull/272)
    -   Removed `IsCallable` check on `NextMethod`, deferring errors to `Call` site, [May 2023 TC39 meeting](https://github.com/tc39/notes/blob/main/meetings/2023-05/may-16.md#iterator-helpers-should-malformed-iterators-fail-early-or-fail-only-when-iterated), [proposal-iterator-helpers/274](https://github.com/tc39/proposal-iterator-helpers/pull/274)
-   Added [`Promise.withResolvers` stage 2 proposal](https://github.com/tc39/proposal-promise-with-resolvers):
    -   `Promise.withResolvers` method
-   [`Symbol` predicates stage 2 proposal](https://github.com/tc39/proposal-symbol-predicates):
    -   The methods renamed to end with `Symbol`, [May 2023 TC39 meeting](https://github.com/tc39/notes/blob/main/meetings/2023-05/may-15.md#symbol-predicates):
        -   `Symbol.isRegistered` -> `Symbol.isRegisteredSymbol` method
        -   `Symbol.isWellKnown` -> `Symbol.isWellKnownSymbol` method
-   Added `value` argument of `URLSearchParams.prototype.{ has, delete }`, [url/735](https://github.com/whatwg/url/pull/735)
-   Fixed some cases of increasing buffer size in `ArrayBuffer.prototype.{ transfer, transferToFixedLength }` polyfills
-   Fixed awaiting async `AsyncDisposableStack.prototype.adopt` callback, [#&#8203;1258](https://github.com/zloirock/core-js/issues/1258)
-   Fixed `URLSearchParams#size` in ES3 engines (IE8-)
-   Added a workaround in `Object.{ entries, values }` for some IE versions bug with invisible integer keys on `null`-prototype objects
-   Added TypeScript definitions to `core-js-compat`, [#&#8203;1235](https://github.com/zloirock/core-js/issues/1235), thanks [**@&#8203;susnux**](https://github.com/susnux)
-   Compat data improvements:
    -   [`Set.prototype.difference`](https://github.com/tc39/proposal-set-methods) that was missed in Bun because of [a bug](https://github.com/oven-sh/bun/issues/2309) added in 0.6.0
    -   `Array.prototype.{ group, groupToMap }` marked as no longer supported in WebKit runtimes because of the mentioned above web compat issue. For example, it's disabled from Bun 0.6.2
    -   Methods from the [change `Array` by copy proposal](https://github.com/tc39/proposal-change-array-by-copy) marked as supported from FF115
    -   [`Array.fromAsync`](https://github.com/tc39/proposal-array-from-async) marked as supported from FF115
    -   [`URL.canParse`](https://url.spec.whatwg.org/#dom-url-canparse) marked as supported from FF115
    -   `value` argument of `URLSearchParams.prototype.{ has, delete }` marked as supported from [NodeJS 20.2.0](https://github.com/nodejs/node/pull/47885) and FF115
    -   Added Deno 1.34 compat data mapping
    -   Added Electron 26 compat data mapping
    -   Added Samsung Internet 22 compat data mapping
    -   Added Opera Android 75 and 76 compat data mapping
    -   Added Quest Browser 27 compat data mapping

### [`v3.30.2`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3302---20230507)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.30.1...v3.30.2)

-   Added a fix for a NodeJS 20.0.0 [bug](https://github.com/nodejs/node/issues/47612) with cloning `File` via `structuredClone`
-   Added protection from Terser unsafe `String` optimization, [#&#8203;1242](https://github.com/zloirock/core-js/issues/1242)
-   Added a workaround for getting proper global object in Figma plugins, [#&#8203;1231](https://github.com/zloirock/core-js/issues/1231)
-   Compat data improvements:
    -   Added NodeJS 20.0 compat data mapping
    -   Added Deno 1.33 compat data mapping
    -   [`URL.canParse`](https://url.spec.whatwg.org/#dom-url-canparse) marked as supported (fixed) from [NodeJS 20.1.0](https://github.com/nodejs/node/pull/47513) and [Deno 1.33.2](https://github.com/denoland/deno/pull/18896)

### [`v3.30.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3301---20230414)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.30.0...v3.30.1)

-   Added a fix for a NodeJS 19.9.0 `URL.canParse` [bug](https://github.com/nodejs/node/issues/47505)
-   Compat data improvements:
    -   [`JSON.parse` source text access proposal](https://github.com/tc39/proposal-json-parse-with-source) features marked as [supported](https://chromestatus.com/feature/5121582673428480) from V8 ~ Chrome 114
    -   [`ArrayBuffer.prototype.transfer` and friends proposal](https://github.com/tc39/proposal-arraybuffer-transfer) features marked as [supported](https://chromestatus.com/feature/5073244152922112) from V8 ~ Chrome 114
    -   [`URLSearchParams.prototype.size`](https://github.com/whatwg/url/pull/734) marked as supported from V8 ~ Chrome 113

### [`v3.30.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3300---20230404)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.29.1...v3.30.0)

-   Added [`URL.canParse` method](https://url.spec.whatwg.org/#dom-url-canparse), [url/763](https://github.com/whatwg/url/pull/763)
-   [`Set` methods proposal](https://github.com/tc39/proposal-set-methods):
    -   Removed sort from `Set.prototype.intersection`, [March 2023 TC39 meeting](https://github.com/babel/proposals/issues/87#issuecomment-1478610425), [proposal-set-methods/94](https://github.com/tc39/proposal-set-methods/pull/94)
-   Iterator Helpers proposals ([sync](https://github.com/tc39/proposal-iterator-helpers), [async](https://github.com/tc39/proposal-async-iterator-helpers)):
    -   Validate arguments before opening iterator, [March 2023 TC39 meeting](https://github.com/babel/proposals/issues/87#issuecomment-1478412430), [proposal-iterator-helpers/265](https://github.com/tc39/proposal-iterator-helpers/pull/265)
-   Explicit Resource Management proposals ([sync](https://github.com/tc39/proposal-explicit-resource-management), [async](https://github.com/tc39/proposal-async-explicit-resource-management)):
    -   `(Async)DisposableStack.prototype.move` marks the original stack as disposed, [#&#8203;1226](https://github.com/zloirock/core-js/issues/1226)
    -   Some simplifications like [proposal-explicit-resource-management/150](https://github.com/tc39/proposal-explicit-resource-management/pull/150)
-   [`Iterator.range` proposal](https://github.com/tc39/proposal-Number.range):
    -   Moved to Stage 2, [March 2023 TC39 meeting](https://github.com/babel/proposals/issues/87#issuecomment-1480266760)
-   [Decorator Metadata proposal](https://github.com/tc39/proposal-decorator-metadata):
    -   Returned to usage `Symbol.metadata`, [March 2023 TC39 meeting](https://github.com/babel/proposals/issues/87#issuecomment-1478790137), [proposal-decorator-metadata/12](https://github.com/tc39/proposal-decorator-metadata/pull/12)
-   Compat data improvements:
    -   [`URLSearchParams.prototype.size`](https://github.com/whatwg/url/pull/734) marked as supported from FF112, NodeJS 19.8 and Deno 1.32
    -   Added Safari 16.4 compat data
    -   Added Deno 1.32 compat data mapping
    -   Added Electron 25 and updated 24 compat data mapping
    -   Added Samsung Internet 21 compat data mapping
    -   Added Quest Browser 26 compat data mapping
    -   Updated Opera Android 74 compat data

### [`v3.29.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3291---20230313)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.29.0...v3.29.1)

-   Fixed dependencies of some entries
-   Fixed `ToString` conversion / built-ins nature of some accessors
-   [`String.prototype.{ isWellFormed, toWellFormed }`](https://github.com/tc39/proposal-is-usv-string) marked as supported from V8 ~ Chrome 111
-   Added Opera Android 74 compat data mapping

### [`v3.29.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3290---20230227)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.28.0...v3.29.0)

-   Added `URLSearchParams.prototype.size` getter, [url/734](https://github.com/whatwg/url/pull/734)
-   Allowed cloning resizable `ArrayBuffer`s in the `structuredClone` polyfill
-   Fixed wrong export in `/(stable|actual|full)/instance/unshift` entries, [#&#8203;1207](https://github.com/zloirock/core-js/issues/1207)
-   Compat data improvements:
    -   [`Set` methods proposal](https://github.com/tc39/proposal-set-methods) marked as supported from Bun 0.5.7
    -   `String.prototype.toWellFormed` marked as fixed from Bun 0.5.7
    -   Added Deno 1.31 compat data mapping

### [`v3.28.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3280---20230214)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.27.2...v3.28.0)

##### [3.28.0 - 2023.02.14](https://github.com/zloirock/core-js/releases/tag/v3.28.0)

### [`v3.27.2`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3272---20230119)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.27.1...v3.27.2)

-   [`Set` methods proposal](https://github.com/tc39/proposal-set-methods) updates:
    -   Closing of iterators of `Set`-like objects on early exit, [proposal-set-methods/85](https://github.com/tc39/proposal-set-methods/pull/85)
    -   Some other minor internal changes
-   Added one more workaround of a `webpack` dev server bug on IE global methods, [#&#8203;1161](https://github.com/zloirock/core-js/issues/1161)
-   Fixed possible `String.{ raw, cooked }` error with empty template array
-   Used non-standard V8 `Error.captureStackTrace` instead of stack parsing in new error classes / wrappers where it's possible
-   Added detection correctness of iteration to `Promise.{ allSettled, any }` feature detection, Hermes issue
-   Compat data improvements:
    -   [Change `Array` by copy proposal](https://github.com/tc39/proposal-change-array-by-copy) marked as supported from V8 ~ Chrome 110
    -   Added Samsung Internet 20 compat data mapping
    -   Added Quest Browser 25 compat data mapping
    -   Added React Native 0.71 Hermes compat data
    -   Added Electron 23 and 24 compat data mapping
    -   `self` marked as fixed in Deno 1.29.3, [deno/17362](https://github.com/denoland/deno/pull/17362)
-   Minor tweaks of minification settings for `core-js-bundle`
-   Refactoring, some minor fixes, improvements, optimizations

### [`v3.27.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3271---20221230)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.27.0...v3.27.1)

-   Fixed a Chakra-based MS Edge (18-) bug that unfreeze (O_o) frozen arrays used as `WeakMap` keys
-   Fixing of the previous bug also fixes some cases of `String.dedent` in MS Edge
-   Fixed dependencies of some entries

### [`v3.27.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3270---20221226)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.26.1...v3.27.0)

-   [Iterator Helpers](https://github.com/tc39/proposal-iterator-helpers) proposal:
    -   Built-ins:
        -   `Iterator`
            -   `Iterator.from`
            -   `Iterator.prototype.drop`
            -   `Iterator.prototype.every`
            -   `Iterator.prototype.filter`
            -   `Iterator.prototype.find`
            -   `Iterator.prototype.flatMap`
            -   `Iterator.prototype.forEach`
            -   `Iterator.prototype.map`
            -   `Iterator.prototype.reduce`
            -   `Iterator.prototype.some`
            -   `Iterator.prototype.take`
            -   `Iterator.prototype.toArray`
            -   `Iterator.prototype.toAsync`
            -   `Iterator.prototype[@&#8203;@&#8203;toStringTag]`
        -   `AsyncIterator`
            -   `AsyncIterator.from`
            -   `AsyncIterator.prototype.drop`
            -   `AsyncIterator.prototype.every`
            -   `AsyncIterator.prototype.filter`
            -   `AsyncIterator.prototype.find`
            -   `AsyncIterator.prototype.flatMap`
            -   `AsyncIterator.prototype.forEach`
            -   `AsyncIterator.prototype.map`
            -   `AsyncIterator.prototype.reduce`
            -   `AsyncIterator.prototype.some`
            -   `AsyncIterator.prototype.take`
            -   `AsyncIterator.prototype.toArray`
            -   `AsyncIterator.prototype[@&#8203;@&#8203;toStringTag]`
    -   Moved to Stage 3, [November 2022 TC39 meeting](https://github.com/babel/proposals/issues/85#issuecomment-1333474304)
    -   Added `/actual/` entries, unconditional forced replacement disabled for features that survived to Stage 3
    -   `.from` accept strings, `.flatMap` throws on strings returned from the callback, [proposal-iterator-helpers/244](https://github.com/tc39/proposal-iterator-helpers/pull/244), [proposal-iterator-helpers/250](https://github.com/tc39/proposal-iterator-helpers/pull/250)
    -   `.from` and `.flatMap` throws on non-object *iterators*, [proposal-iterator-helpers/253](https://github.com/tc39/proposal-iterator-helpers/pull/253)
-   [`Set` methods proposal](https://github.com/tc39/proposal-set-methods):
    -   Built-ins:
        -   `Set.prototype.intersection`
        -   `Set.prototype.union`
        -   `Set.prototype.difference`
        -   `Set.prototype.symmetricDifference`
        -   `Set.prototype.isSubsetOf`
        -   `Set.prototype.isSupersetOf`
        -   `Set.prototype.isDisjointFrom`
    -   Moved to Stage 3, [November 2022 TC39 meeting](https://github.com/babel/proposals/issues/85#issuecomment-1332175557)
    -   Reimplemented with [new semantics](https://tc39.es/proposal-set-methods/):
        -   Optimized performance (iteration over lowest set)
        -   Accepted only `Set`-like objects as an argument, not all iterables
        -   Accepted only `Set`s as `this`, no `@@&#8203;species` support, and other minor changes
    -   Added `/actual/` entries, unconditional forced replacement changed to feature detection
    -   For avoiding breaking changes:
        -   New versions of methods are implemented as new modules and available in new entries or entries where old versions of methods were not available before (like `/actual/` namespace)
        -   In entries where they were available before (like `/full/` namespace), those methods are available with fallbacks to old semantics (in addition to `Set`-like, they accept iterable objects). This behavior will be removed from the next major release
-   [Well-Formed Unicode Strings](https://github.com/tc39/proposal-is-usv-string) proposal:
    -   Methods:
        -   `String.prototype.isWellFormed`
        -   `String.prototype.toWellFormed`
    -   Moved to Stage 3, [November 2022 TC39 meeting](https://github.com/babel/proposals/issues/85#issuecomment-1332180862)
    -   Added `/actual/` entries, disabled unconditional forced replacement
-   [Explicit resource management](https://github.com/tc39/proposal-explicit-resource-management) Stage 3 and [Async explicit resource management](https://github.com/tc39/proposal-async-explicit-resource-management) Stage 2 proposals:
    -   Renamed from "`using` statement" and [split into 2 (sync and async) proposals](https://github.com/tc39/proposal-explicit-resource-management/pull/131)
    -   In addition to already present well-known symbols, added new built-ins:
        -   `Symbol.dispose`
        -   `Symbol.asyncDispose`
        -   `SuppressedError`
        -   `DisposableStack`
            -   `DisposableStack.prototype.dispose`
            -   `DisposableStack.prototype.use`
            -   `DisposableStack.prototype.adopt`
            -   `DisposableStack.prototype.defer`
            -   `DisposableStack.prototype.move`
            -   `DisposableStack.prototype[@&#8203;@&#8203;dispose]`
        -   `AsyncDisposableStack`
            -   `AsyncDisposableStack.prototype.disposeAsync`
            -   `AsyncDisposableStack.prototype.use`
            -   `AsyncDisposableStack.prototype.adopt`
            -   `AsyncDisposableStack.prototype.defer`
            -   `AsyncDisposableStack.prototype.move`
            -   `AsyncDisposableStack.prototype[@&#8203;@&#8203;asyncDispose]`
        -   `Iterator.prototype[@&#8203;@&#8203;dispose]`
        -   `AsyncIterator.prototype[@&#8203;@&#8203;asyncDispose]`
    -   Sync version of this proposal moved to Stage 3, [November 2022 TC39 meeting](https://github.com/babel/proposals/issues/85#issuecomment-1333747094)
    -   Added `/actual/` namespace entries for Stage 3 proposal
-   Added [`String.dedent` stage 2 proposal](https://github.com/tc39/proposal-string-dedent)
    -   Method `String.dedent`
    -   Throws an error on non-frozen raw templates for avoiding possible breaking changes in the future, [proposal-string-dedent/75](https://github.com/tc39/proposal-string-dedent/issues/75)
-   [Compat data targets](/packages/core-js-compat#targets-option) improvements:
    -   [React Native from 0.70 shipped with Hermes as the default engine.](https://reactnative.dev/blog/2022/07/08/hermes-as-the-default) However, bundled Hermes versions differ from standalone Hermes releases. So added **`react-native`** target for React Native with bundled Hermes.
    -   [According to the documentation](https://developer.oculus.com/documentation/web/browser-intro/), Oculus Browser was renamed to Meta Quest Browser, so `oculus` target was renamed to **`quest`**.
    -   `opera_mobile` target name is confusing since it contains data for the Chromium-based Android version, but iOS Opera is Safari-based. So `opera_mobile` target was renamed to **`opera-android`**.
    -   `android` target name is also confusing for someone - that means Android WebView, some think thinks that it's Chrome for Android, but they have some differences. For avoiding confusion, added **`chrome-android`** target.
    -   For consistency with two previous cases, added **`firefox-android`** target.
    -   For avoiding breaking changes, the `oculus` and `opera_mobile` fields are available in the compat data till the next major release.
-   Compat data improvements:
    -   [`Array.fromAsync`](https://github.com/tc39/proposal-array-from-async) marked as supported from Bun 0.3.0
    -   [`String.prototype.{ isWellFormed, toWellFormed }`](https://github.com/tc39/proposal-is-usv-string) marked as supported from Bun 0.4.0
    -   [Change `Array` by copy proposal](https://github.com/tc39/proposal-change-array-by-copy) marked as supported from Deno 1.27, [deno/16429](https://github.com/denoland/deno/pull/16429)
    -   Added Deno 1.28 / 1.29 compat data mapping
    -   Added NodeJS 19.2 compat data mapping
    -   Added Samsung Internet 19.0 compat data mapping
    -   Added Quest Browser 24.0 compat data mapping
    -   Fixed the first version in the Chromium-based Edge compat data mapping
-   `{ Map, WeakMap }.prototype.emplace` became stricter [by the spec draft](https://tc39.es/proposal-upsert/)
-   Smoothed behavior of some conflicting proposals
-   Removed some generic behavior (like `@@&#8203;species` pattern) of some `.prototype` methods from the [new collections methods proposal](https://github.com/tc39/proposal-collection-methods) and the [`Array` deduplication proposal](https://github.com/tc39/proposal-array-unique) that *most likely* will not be implemented since it contradicts the current TC39 policy
-   Added pure version of the `Number` constructor, [#&#8203;1154](https://github.com/zloirock/core-js/issues/1154), [#&#8203;1155](https://github.com/zloirock/core-js/issues/1155), thanks [@&#8203;trosos](https://github.com/trosos)
-   Added `set(Timeout|Interval|Immediate)` extra arguments fix for Bun 0.3.0- (similarly to IE9-), [bun/1633](https://github.com/oven-sh/bun/issues/1633)
-   Fixed handling of sparse arrays in `structuredClone`, [#&#8203;1156](https://github.com/zloirock/core-js/issues/1156)
-   Fixed a theoretically possible future conflict of polyfills definitions in the pure version
-   Some refactoring and optimization

### [`v3.26.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3261---20221114)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.26.0...v3.26.1)

-   Disabled forced replacing of `Array.fromAsync` since it's on Stage 3
-   Avoiding a check of the target in the internal `function-uncurry-this` helper where it's not required - minor optimization and preventing problems in some broken environments, a workaround of [#&#8203;1141](https://github.com/zloirock/core-js/issues/1141)
-   V8 will not ship `Array.prototype.{ group, groupToMap }` in V8 ~ Chromium 108, [proposal-array-grouping/44](https://github.com/tc39/proposal-array-grouping/issues/44#issuecomment-1306311107)

### [`v3.26.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3260---20221024)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.25.5...v3.26.0)

-   [`Array.fromAsync` proposal](https://github.com/tc39/proposal-array-from-async):
    -   Moved to Stage 3, [September TC39 meeting](https://github.com/tc39/notes/blob/main/meetings/2022-09/sep-14.md#arrayfromasync-for-stage-3)
    -   Avoid observable side effects of `%Array.prototype.values%` usage in array-like branch, [proposal-array-from-async/30](https://github.com/tc39/proposal-array-from-async/pull/30)
-   Added [well-formed unicode strings stage 2 proposal](https://github.com/tc39/proposal-is-usv-string):
    -   `String.prototype.isWellFormed`
    -   `String.prototype.toWellFormed`
-   Recent updates of the [iterator helpers proposal](https://github.com/tc39/proposal-iterator-helpers):
    -   Added a counter parameter to helpers, [proposal-iterator-helpers/211](https://github.com/tc39/proposal-iterator-helpers/pull/211)
    -   Don't await non-objects returned from functions passed to `AsyncIterator` helpers, [proposal-iterator-helpers/239](https://github.com/tc39/proposal-iterator-helpers/pull/239)
    -   `{ Iterator, AsyncIterator }.prototype.flatMap` supports returning both - iterables and iterators, [proposal-iterator-helpers/233](https://github.com/tc39/proposal-iterator-helpers/pull/233)
    -   Early exit on broken `.next` in missed cases of `{ Iterator, AsyncIterator }.from`, [proposal-iterator-helpers/232](https://github.com/tc39/proposal-iterator-helpers/pull/232)
-   Added `self` polyfill as a part of [The Minimum Common Web Platform API](https://common-min-api.proposal.wintercg.org/), [specification](https://html.spec.whatwg.org/multipage/window-object.html#dom-self), [#&#8203;1118](https://github.com/zloirock/core-js/issues/1118)
-   Added `inverse` option to `core-js-compat`, [#&#8203;1119](https://github.com/zloirock/core-js/issues/1119)
-   Added `format` option to `core-js-builder`, [#&#8203;1120](https://github.com/zloirock/core-js/issues/1120)
-   Added NodeJS 19.0 compat data
-   Added Deno 1.26 and 1.27 compat data
-   Added Opera Android 72 compat data mapping
-   Updated Electron 22 compat data mapping

### [`v3.25.5`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3255---20221004)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.25.4...v3.25.5)

-   Fixed regression with an error on reuse of some built-in methods from another realm, [#&#8203;1133](https://github.com/zloirock/core-js/issues/1133)

### [`v3.25.4`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3254---20221003)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.25.3...v3.25.4)

-   Added a workaround of a Nashorn bug with `Function.prototype.{ call, apply, bind }` on string methods, [#&#8203;1128](https://github.com/zloirock/core-js/issues/1128)
-   Updated lists of `[Serializable]` and `[Transferable]` objects in the `structuredClone` polyfill. Mainly, for better error messages if polyfilling of cloning such types is impossible
-   `Array.prototype.{ group, groupToMap }` marked as [supported from V8 ~ Chromium 108](https://chromestatus.com/feature/5714791975878656)
-   Added Electron 22 compat data mapping

### [`v3.25.3`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3253---20220926)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.25.2...v3.25.3)

-   Forced polyfilling of `Array.prototype.groupToMap` in the pure version for returning wrapped `Map` instances
-   Fixed existence of `Array.prototype.{ findLast, findLastIndex }` in `/stage/4` entry
-   Added Opera Android 71 compat data mapping
-   Some stylistic changes

### [`v3.25.2`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3252---20220919)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.25.1...v3.25.2)

-   Considering `document.all` as a callable in some missed cases
-   Added Safari 16.0 compat data
-   Added iOS Safari 16.0 compat data mapping
-   Fixed some ancient iOS Safari versions compat data mapping

### [`v3.25.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3251---20220908)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.25.0...v3.25.1)

-   Added some fixes and workarounds of FF30- typed arrays bug that does not properly convert objects to numbers
-   Added `sideEffects` field to `core-js-pure` `package.json` for better tree shaking, [#&#8203;1117](https://github.com/zloirock/core-js/issues/1117)
-   Dropped `semver` dependency from `core-js-compat`
    -   `semver` package (ironically) added [a breaking change and dropped NodeJS 8 support in the minor `7.1` version](https://github.com/npm/node-semver/commit/d61f828e64260a0a097f26210f5500), after that `semver` in `core-js-compat` was pinned to `7.0` since for avoiding breaking changes it should support NodeJS 8. However, since `core-js-compat` is usually used with other packages that use `semver` dependency, it causes multiple duplication of `semver` in dependencies. So I decided to remove `semver` dependency and replace it with a couple of simple helpers.
-   Added Bun 0.1.6-0.1.11 compat data
-   Added Deno 1.25 compat data mapping
-   Updated Electron 21 compat data mapping
-   Some stylistic changes, minor fixes, and improvements

### [`v3.25.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3250---20220825)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.24.1...v3.25.0)

-   Added [`Object.prototype.__proto__`](https://tc39.es/ecma262/#sec-object.prototype.\__proto\_\_) polyfill
    -   It's optional, legacy, and in some cases (mainly because of developers' mistakes) can cause problems, but [some libraries depend on it](https://github.com/denoland/deno/issues/13321), and most code can't work without the proper libraries' ecosystem
    -   Only for modern engines where this feature is missed (like Deno), it's not installed in IE10- since here we have no proper way setting of the prototype
    -   Without fixes of early implementations where it's not an accessor since those fixes are impossible
    -   Only for the global version
-   Considering `document.all` as an object in some missed cases, see [ECMAScript Annex B 3.6](https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot)
-   Avoiding unnecessary promise creation and validation result in `%WrapForValid(Async)IteratorPrototype%.return`, [proposal-iterator-helpers/215](https://github.com/tc39/proposal-iterator-helpers/pull/215)
-   Fixed omitting the result of proxing `.return` in `%IteratorHelperPrototype%.return`, [#&#8203;1116](https://github.com/zloirock/core-js/issues/1116)
-   Fixed the order creation of properties of iteration result object of some iterators (`value` should be created before `done`)
-   Fixed some cases of Safari < 13 bug - silent on non-writable array `.length` setting
-   Fixed `ArrayBuffer.length` in V8 ~ Chrome 27-
-   Relaxed condition of re-usage native `WeakMap` for internal states with multiple `core-js` copies
-   Availability cloning of `FileList` in the `structuredClone` polyfill extended to some more old engines versions
-   Some stylistic changes and minor fixes
-   Throwing a `TypeError` in `core-js-compat` / `core-js-builder` in case of passing invalid module names / filters for avoiding unexpected result, related to [#&#8203;1115](https://github.com/zloirock/core-js/issues/1115)
-   Added missed NodeJS 13.2 to `esmodules` `core-js-compat` / `core-js-builder` target
-   Added Electron 21 compat data mapping
-   Added Oculus Browser 23.0 compat data mapping

### [`v3.24.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3241---20220730)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.24.0...v3.24.1)

-   NodeJS is ignored in `IS_BROWSER` detection to avoid a false positive with `jsdom`, [#&#8203;1110](https://github.com/zloirock/core-js/issues/1110)
-   Fixed detection of `@@&#8203;species` support in `Promise` in some old engines
-   `{ Array, %TypedArray% }.prototype.{ findLast, findLastIndex }` marked as shipped [in FF104](https://bugzilla.mozilla.org/show_bug.cgi?id=1775026)
-   Added iOS Safari 15.6 compat data mapping
-   Fixed Opera 15 compat data mapping

### [`v3.24.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3240---20220725)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.23.5...v3.24.0)

-   Recent updates of the [iterator helpers proposal](https://github.com/tc39/proposal-iterator-helpers), [#&#8203;1101](https://github.com/zloirock/core-js/issues/1101):
    -   `.asIndexedPairs` renamed to `.indexed`, [proposal-iterator-helpers/183](https://github.com/tc39/proposal-iterator-helpers/pull/183):
        -   `Iterator.prototype.asIndexedPairs` -> `Iterator.prototype.indexed`
        -   `AsyncIterator.prototype.asIndexedPairs` -> `AsyncIterator.prototype.indexed`
    -   Avoid exposing spec fiction `%AsyncFromSyncIteratorPrototype%` in `AsyncIterator.from` and `Iterator.prototype.toAsync`, [proposal-iterator-helpers/182](https://github.com/tc39/proposal-iterator-helpers/pull/182), [proposal-iterator-helpers/202](https://github.com/tc39/proposal-iterator-helpers/pull/202)
    -   Avoid unnecessary promise creation in `%WrapForValidAsyncIteratorPrototype%.next`, [proposal-iterator-helpers/197](https://github.com/tc39/proposal-iterator-helpers/pull/197)
    -   Do not validate value in `%WrapForValid(Async)IteratorPrototype%.next`, [proposal-iterator-helpers/197](https://github.com/tc39/proposal-iterator-helpers/pull/197) and [proposal-iterator-helpers/205](https://github.com/tc39/proposal-iterator-helpers/pull/205)
    -   Do not forward the parameter of `.next` / `.return` to an underlying iterator by the extended iterator protocol, a part of [proposal-iterator-helpers/194](https://github.com/tc39/proposal-iterator-helpers/pull/194)
    -   `.throw` methods removed from all wrappers / helpers prototypes, a part of [proposal-iterator-helpers/194](https://github.com/tc39/proposal-iterator-helpers/pull/194)
    -   Close inner iterators of `{ Iterator, AsyncIterator }.prototype.flatMap` proxy iterators on `.return`, [proposal-iterator-helpers/195](https://github.com/tc39/proposal-iterator-helpers/pull/195)
    -   Throw `RangeError` on `NaN` in `{ Iterator, AsyncIterator }.prototype.{ drop, take }`, [proposal-iterator-helpers/181](https://github.com/tc39/proposal-iterator-helpers/pull/181)
    -   Many other updates and fixes of this proposal
-   `%TypedArray%.prototype.toSpliced` method removed from the [change array by copy proposal](https://github.com/tc39/proposal-change-array-by-copy) and marked as obsolete in `core-js`, [proposal-change-array-by-copy/88](https://github.com/tc39/proposal-change-array-by-copy/issues/88)
-   Polyfill `Promise` with `unhandledrejection` event support (browser style) in Deno < [1.24](https://github.com/denoland/deno/releases/tag/v1.24.0)
-   Available new targets in `core-js-compat` / `core-js-builder` and added compat data for them:
    -   Bun (`bun`), compat data for 0.1.1-0.1.5, [#&#8203;1103](https://github.com/zloirock/core-js/issues/1103)
    -   Hermes (`hermes`), compat data for 0.1-0.11, [#&#8203;1099](https://github.com/zloirock/core-js/issues/1099)
    -   Oculus Browser (`oculus`), compat data mapping for 3.0-22.0, [#&#8203;1098](https://github.com/zloirock/core-js/issues/1098)
-   Added Samsung Internet 18.0 compat data mapping

### [`v3.23.5`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3235---20220718)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.23.4...v3.23.5)

-   Fixed a typo in the `structuredClone` feature detection, [#&#8203;1106](https://github.com/zloirock/core-js/issues/1106)
-   Added Opera Android 70 compat data mapping

### [`v3.23.4`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3234---20220710)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.23.3...v3.23.4)

-   Added a workaround of the Bun ~ 0.1.1 [bug](https://github.com/Jarred-Sumner/bun/issues/399) that define some globals with incorrect property descriptors and that causes a crash of `core-js`
-   Added a fix of the FF103+ `structuredClone` bugs ([1774866](https://bugzilla.mozilla.org/show_bug.cgi?id=1774866) (fixed in FF104) and [1777321](https://bugzilla.mozilla.org/show_bug.cgi?id=1777321) (still not fixed)) that now can clone errors, but `.stack` of the clone is an empty string
-   Fixed `{ Map, WeakMap }.prototype.emplace` logic, [#&#8203;1102](https://github.com/zloirock/core-js/issues/1102)
-   Fixed order of errors throwing on iterator helpers

### [`v3.23.3`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3233---20220626)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.23.2...v3.23.3)

-   Changed the order of operations in `%TypedArray%.prototype.toSpliced` following [proposal-change-array-by-copy/89](https://github.com/tc39/proposal-change-array-by-copy/issues/89)
-   Fixed regression of some IE8- issues

### [`v3.23.2`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3232---20220621)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.23.1...v3.23.2)

-   Avoided creation of extra properties for the handling of `%TypedArray%` constructors in new methods, [#&#8203;1092 (comment)](https://github.com/zloirock/core-js/issues/1092#issuecomment-1158760512)
-   Added Deno 1.23 compat data mapping

### [`v3.23.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3231---20220614)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.23.0...v3.23.1)

-   Fixed possible error on multiple `core-js` copies, [#&#8203;1091](https://github.com/zloirock/core-js/issues/1091)
-   Added `v` flag to `RegExp.prototype.flags` implementation in case if current V8 bugs will not be fixed before this flag implementation

### [`v3.23.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3230---20220614)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.22.8...v3.23.0)

-   [`Array` find from last](https://github.com/tc39/proposal-array-find-from-last) moved to the stable ES, according to June 2022 TC39 meeting:
    -   `Array.prototype.findLast`
    -   `Array.prototype.findLastIndex`
    -   `%TypedArray%.prototype.findLast`
    -   `%TypedArray%.prototype.findLastIndex`
-   Methods from [the `Array` grouping proposal](https://github.com/tc39/proposal-array-grouping) [renamed](https://github.com/tc39/proposal-array-grouping/pull/39), according to June 2022 TC39 meeting:
    -   `Array.prototype.groupBy` -> `Array.prototype.group`
    -   `Array.prototype.groupByToMap` -> `Array.prototype.groupToMap`
-   Changed the order of operations in `%TypedArray%.prototype.with` following [proposal-change-array-by-copy/86](https://github.com/tc39/proposal-change-array-by-copy/issues/86), according to June 2022 TC39 meeting
-   [Decorator Metadata proposal](https://github.com/tc39/proposal-decorator-metadata) extracted from [Decorators proposal](https://github.com/tc39/proposal-decorators) as a separate stage 2 proposal, according to March 2022 TC39 meeting, `Symbol.metadataKey` replaces `Symbol.metadata`
-   Added `Array.prototype.push` polyfill with some fixes for modern engines
-   Added `Array.prototype.unshift` polyfill with some fixes for modern engines
-   Fixed a bug in the order of getting flags in `RegExp.prototype.flags` in the actual version of V8
-   Fixed property descriptors of some `Math` and `Number` constants
-   Added a workaround of V8 `ArrayBufferDetaching` protector cell invalidation and performance degradation on `structuredClone` feature detection, one more case of [#&#8203;679](https://github.com/zloirock/core-js/issues/679)
-   Added detection of NodeJS [bug](https://github.com/nodejs/node/issues/41038) in `structuredClone` that can not clone `DOMException` (just in case for future versions that will fix other issues)
-   Compat data:
    -   Added NodeJS 18.3 compat data mapping
    -   Added and fixed Deno 1.22 and 1.21 compat data mapping
    -   Added Opera Android 69 compat data mapping
    -   Updated Electron 20.0 compat data mapping

### [`v3.22.8`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3228---20220602)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.22.7...v3.22.8)

-   Fixed possible multiple call of `ToBigInt` / `ToNumber` conversion of the argument passed to `%TypedArray%.prototype.fill` in V8 ~ Chrome < 59, Safari < 14.1, FF < 55, Edge <=18
-   Fixed some cases of `DeletePropertyOrThrow` in IE9-
-   Fixed the kind of error (`TypeError` instead of `Error`) on incorrect `exec` result in `RegExp.prototype.test` polyfill
-   Fixed dependencies of `{ actual, full, features }/typed-array/at` entries
-   Added Electron 20.0 compat data mapping
-   Added iOS Safari 15.5 compat data mapping
-   Refactoring

### [`v3.22.7`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3227---20220524)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.22.6...v3.22.7)

-   Added a workaround for V8 ~ Chrome 53 bug with non-writable prototype of some methods, [#&#8203;1083](https://github.com/zloirock/core-js/issues/1083)

### [`v3.22.6`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3226---20220523)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.22.5...v3.22.6)

-   Fixed possible double call of `ToNumber` conversion on arguments of `Math.{ fround, trunc }` polyfills
-   `Array.prototype.includes` marked as [fixed](https://bugzilla.mozilla.org/show_bug.cgi?id=1767541) in FF102

### [`v3.22.5`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3225---20220510)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.22.4...v3.22.5)

-   Ensured that polyfilled constructors `.prototype` is non-writable
-   Ensured that polyfilled methods `.prototype` is not defined
-   Added detection and fix of a V8 ~ Chrome <103 [bug](https://bugs.chromium.org/p/v8/issues/detail?id=12542) of `struturedClone` that returns `null` if cloned object contains multiple references to one error

### [`v3.22.4`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3224---20220503)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.22.3...v3.22.4)

-   Ensured proper `.length` of polyfilled functions even in compressed code (excepting some ancient engines)
-   Ensured proper `.name` of polyfilled accessors (excepting some ancient engines)
-   Ensured proper source / `ToString` conversion of polyfilled accessors
-   Actualized Rhino compat data
-   Refactoring

### [`v3.22.3`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3223---20220428)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.22.2...v3.22.3)

-   Added a fix for FF99+ `Array.prototype.includes` broken on sparse arrays

### [`v3.22.2`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3222---20220421)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.22.1...v3.22.2)

-   Fixed `URLSearchParams` in IE8- that was broken in the previous release
-   Fixed `__lookupGetter__` entries

### [`v3.22.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3221---20220420)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.22.0...v3.22.1)

-   Improved some cases of `RegExp` flags handling
-   Prevented experimental warning in NodeJS ~ 18.0 on detection `fetch` API
-   Added NodeJS 18.0 compat data

### [`v3.22.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3220---20220415)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.21.1...v3.22.0)

-   [Change `Array` by copy proposal](https://github.com/tc39/proposal-change-array-by-copy):
    -   Moved to Stage 3, [March TC39 meeting](https://github.com/babel/proposals/issues/81#issuecomment-1083449843)
    -   Disabled forced replacement and added `/actual/` entry points for methods from this proposal
    -   `Array.prototype.toSpliced` throws a `TypeError` instead of `RangeError` if the result length is more than `MAX_SAFE_INTEGER`, [proposal-change-array-by-copy/70](https://github.com/tc39/proposal-change-array-by-copy/pull/70)
-   Added some more `atob` / `btoa` fixes:
    -   NodeJS <17.9 `atob` does not ignore spaces, [node/42530](https://github.com/nodejs/node/issues/42530)
    -   Actual NodeJS `atob` does not validate encoding, [node/42646](https://github.com/nodejs/node/issues/42646)
    -   FF26- implementation does not properly convert argument to string
    -   IE / Edge <16 implementation have wrong arity
-   Added `/full/` namespace as the replacement for `/features/` since it's more descriptive in context of the rest namespaces (`/es/` ⊆ `/stable/` ⊆ `/actual/` ⊆ `/full/`)
-   Avoided propagation of removed parts of proposals to upper stages. For example, `%TypedArray%.prototype.groupBy` was removed from the `Array` grouping proposal a long time ago. We can't completely remove this method since it's a breaking change. But this proposal has been promoted to stage 3 - so the proposal should be promoted without this method, this method should not be available in `/actual/` entries - but it should be available in early-stage entries to avoid breakage.
-   Significant internal refactoring and splitting of modules (but without exposing to public API since it will be a breaking change - it will be exposed in the next major version)
-   Bug fixes:
    -   Fixed work of non-standard V8 `Error` features with wrapped `Error` constructors, [#&#8203;1061](https://github.com/zloirock/core-js/issues/1061)
    -   `null` and `undefined` allowed as the second argument of `structuredClone`, [#&#8203;1056](https://github.com/zloirock/core-js/issues/1056)
-   Tooling:
    -   Stabilized proposals are filtered out from the `core-js-compat` -> `core-js-builder` -> `core-js-bundle` output. That mean that if the output contains, for example, `es.object.has-own`, the legacy reference to it, `esnext.object.has-own`, no longer added.
    -   Aligned modules filters of [`core-js-builder`](https://github.com/zloirock/core-js/tree/master/packages/core-js-builder) and [`core-js-compat`](https://github.com/zloirock/core-js/tree/master/packages/core-js-compat), now it's `modules` and `exclude` options
    -   Added support of entry points, modules, regexes, and arrays of them to those filters
    -   Missed `targets` option of `core-js-compat` means that the `targets` filter just will not be applied, so the result will contain modules required for all possible engines
-   Compat data:
    -   `.stack` property on `DOMException` marked as supported from Deno [1.15](https://github.com/denoland/deno/releases/tag/v1.15.0)
    -   Added Deno 1.21 compat data mapping
    -   Added Electron 19.0 and updated 18.0 compat data mapping
    -   Added Samsung Internet 17.0 compat data mapping
    -   Added Opera Android 68 compat data mapping

### [`v3.21.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3211---20220217)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.21.0...v3.21.1)

-   Added a [bug](https://bugs.webkit.org/show_bug.cgi?id=236541)fix for the WebKit `Array.prototype.{ groupBy, groupByToMap }` implementation
-   `core-js-compat` targets parser transforms engine names to lower case
-   `atob` / `btoa` marked as [fixed](https://github.com/nodejs/node/pull/41478) in NodeJS 17.5
-   Added Electron 18.0 compat data mapping
-   Added Deno 1.20 compat data mapping

### [`v3.21.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3210---20220202)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.20.3...v3.21.0)

-   Added [Base64 utility methods](https://developer.mozilla.org/en-US/docs/Glossary/Base64):
    -   `atob`
    -   `btoa`
-   Added the proper validation of arguments to some methods from web standards
-   Forced replacement of all features from early-stage proposals for avoiding possible web compatibility issues in the future
-   Added Rhino 1.7.14 compat data
-   Added Deno 1.19 compat data mapping
-   Added Opera Android 66 and 67 compat data mapping
-   Added iOS Safari 15.3 and 15.4 compat data mapping

### [`v3.20.3`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3203---20220115)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.20.2...v3.20.3)

-   Detects and replaces broken third-party `Function#bind` polyfills, uses only native `Function#bind` in the internals
-   `structuredClone` should throw an error if no arguments passed
-   Changed the structure of notes in `__core-js_shared__`

### [`v3.20.2`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3202---20220102)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.20.1...v3.20.2)

-   Added a fix of [a V8 ~ Chrome 36- `Object.{ defineProperty, defineProperties }` bug](https://bugs.chromium.org/p/v8/issues/detail?id=3334), [Babel issue](https://github.com/babel/babel/issues/14056)
-   Added fixes of some different `%TypedArray%.prototype.set` bugs, affects modern engines (like Chrome < 95 or Safari < 14.1)

### [`v3.20.1`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3201---20211223)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.20.0...v3.20.1)

-   Fixed the order of calling reactions of already fulfilled / rejected promises in `Promise.prototype.then`, [#&#8203;1026](https://github.com/zloirock/core-js/issues/1026)
-   Fixed possible memory leak in specific promise chains
-   Fixed some missed dependencies of entries
-   Added Deno 1.18 compat data mapping

### [`v3.20.0`](https://github.com/zloirock/core-js/blob/HEAD/CHANGELOG.md#3200---20211216)

[Compare Source](https://github.com/zloirock/core-js/compare/v3.19.3...v3.20.0)

-   Added `structuredClone` method [from the HTML spec](https://html.spec.whatwg.org/multipage/structured-data.html#dom-structuredclone), [see MDN](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone)
    -   Includes all cases of cloning and transferring of required ECMAScript and platform types that can be polyfilled, for the details see [the caveats](https://github.com/zloirock/core-js#caveats-when-using-structuredclone-polyfill)
    -   Uses native structured cloning algorithm implementations where it's possible
    -   Includes the new semantic of errors cloning from [`html/5749`](https://github.com/whatwg/html/pull/5749)
-   Added `DOMException` polyfill, [the Web IDL spec](https://webidl.spec.whatwg.org/#idl-DOMException), [see MDN](https://developer.mozilla.org/en-US/docs/Web/API/DOMException)
    -   Includes `DOMException` and its attributes polyfills with fi…
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants