-
Notifications
You must be signed in to change notification settings - Fork 127
-
Notifications
You must be signed in to change notification settings - Fork 127
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
When to make --default-type=module
the Node.js default
#1445
Comments
For those wondering, this is what the migration paths look like:
Or, of course, they could refactor code from CommonJS to ESM, but I’m not sure that needs to be presented as an option. This is nothing like Python 2 to 3. The other significant migration is of packages that rely on monkey-patching the CommonJS loader. The authors of major instrumentation libraries and of Yarn Plug-n-Play have been very active engaging with the loaders team in ensuring that the module customization hooks can be used to support their use cases. Those APIs are already in “release candidate” stage, just baking to see if anyone reports any bugs before we declare them stable. Regardless of the |
Doesn’t this mean that users writing a library would have different default behavior for themselves than for when they’re installed in someone else’s node_modules? |
Yes. I think changing that is going to a be a massive breaking change that would break everybody. Most modules would need to keep working with the flag. Other alternatives are
I would personally prefer to ship this in 23, having v24 the first LTS with the change, but I'm not opposed to an accelerated timeline. If we decide not to flip the switch in v22, we could ship some form of warning in v22 for typeless packages outside of node_modules, taking a similar "iteration" approach that we used in the past. Something to consider is the coordination with the TS team, as this will impact them and their resolution algorithms. Of course, Loaders should be stable by then and no critical bugs should be there (or in ESM) to do the switch. |
Let’s investigate this, shall we? Let’s go through some scenarios:
So basically, package authors would need to learn to add the |
Excellent summary @GeoffreyBooth that really clarified how migration would look and it sounds very reasonable. We should also contact npm and ask for:
@nodejs/npm does that sound reasonable? Edit: opened an issue with npm: npm/cli#6855 |
For reference, adding |
Am I following this correctly, that every package that's currently published will stop working once this goes into effect, and only newer versions of those packages that have this field defined will work? |
@wraithgar no, the issue is with the default changing outside node_modules, the issue is when people publish new versions of packages without specifying |
I think this means if you have a simple script like this: // test.js
require('fs') This would stop working once the flag is flipped, unless you change the file name or add a |
Also, wouldn't this break most of our tests unless we do something? (and to that extent, it could probably break a lot of other tests in other projects that are run in a similar "loose" fashion). It could also force all projects not yet migrated to do something, while we already know that there are a lot of simple projects that are not actively maintained but are still heavily depended upon in the ecosystem - or the Node.js ecosystem once favored very simple packages like this, so if an author has tons of very simple packages that do not need much maintenance since Node.js v0.x days (because who would've thought that Node.js is going to break such simple use cases), they will now be forced to update all these small packages. And many of the old reproductions of confirmed bugs would also need updating... |
The “do something” is what I wrote above as the migration path for CommonJS projects with no People seem to keep pointing at Python 2-3 as the only example of a migration, but this is nothing like that: that required everyone to refactor their code, whereas this requires no one to refactor their code. They can if they want to, but this is a configuration change not a syntax change. Yes the “shell scripts” case is the most awkward, because people often lack |
Requiring everyone to add a new file or change file name is no less a problem, I would say, especially considering:
First of all I don't think whatever we put down on that web page is regarded as our principal. There are also a lot of things on that web page is out of sync with how Node.js is used in the wild. Also on that note, the hello world on that page is still using ComomnJS. Second of all, claiming that "Node.js is designed to build scalable network applications." does not mean Node.js is only designed for that and we should disregard other use cases, for example, tooling. Also, can one lose the ability to build a scalable network application just because the default entry type stays the way it is since >10 years ago? I doubt how much difference the default entry type makes if that's the only thing we ever care about.
I think above all Node.js prioritizes stability and not breaking existing code unless absolutely necessary.
Running a |
Yes, many guides to Node.js were written a long time ago. Most people don’t develop “Node apps” per se anymore, they develop in frameworks that build on Node, or with things like TypeScript that use Node. If you look at those docs, most use ESM syntax. @mhdawson do we have any survey data to put some numbers on how people use Node, or what they use it with, or what their preferences are regarding modules? Here’s what happens if you use ESM in a CommonJS context today: mkdir test && cd test
echo 'import "fs"' > entry.js
node entry.js
(node:51228) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension. This would be the inverse experience when we flip the default, in that the message would say something like “Warning: To load a CommonJS module, set
Because the new mode doesn’t affect anything under |
I don't think we should base our decision of such a wide-spread breakage on pure impressions. We need evidence that this is not going to break, say, more than 5% of Node.js users (no matter they are writing code in a framework, or just using Node.js as a runner/tool, or using Node.js inside another environment e.g. cloud provider, desktop environment, or using Node.js to run mod/plugin script), before we can break an API contract that has been by design for >10 years.
By dependencies, I mean that the Node.js application is used as a runner/build tool/a component as part of the project, while developers/users do not necessarily know how to deal with it (e.g. our |
I found the data: https://github.com/nodejs/next-10/tree/main/surveys/2023-04 And in https://github.com/nodejs/next-10/blob/main/surveys/2023-04/Node.js%20Survey%20open%20ended%20answers.pdf, question 18 is “If you wish to use ESM in an existing application, what have been the pain points or blockers preventing you from doing so (if |
I don't think the comparison to Python is fair at all. This is like Python 2/3 if Python 2 code kept working. Namely:
Python 2->3 would have been if we removed CJS entirely, removed all the non-promise callback APIs, removed all deprecated APIs and made breaking changes to promise ones and then created an incompatible Node.js binary effectively making "two Nodes". This on the other hand is just changing the default outside node_modules |
I do not think the survey is created in a way that gathers data about how a widespread breakage in the existing code matter for users. It is true that people may want and do work on transitions when they have time, but it is also true that widespread breakages are disruptive and must be done with care. The right questions should be:
Even in the survey, you can see that more than 30% of the respondents do not plan to migrate to ESM in the near future. I doubt how many of our users would be happy to trade a breakage in a widespread way of running CommonJS in order to speed up migration to ESM. It's not impossible to do forever, but I think we are still very far away from that point. If this only breaks running loose CommonJS files, and if that was really just a niche use case as you described, how much value would this actually bring to the speedup of ESM migration and why is it so urgent that it need to be done in a year? Either this is very widespread and moving on would be an important milestone, or this is just a niche use case so this is one of the last thing that needs to be taken care of. I don't think it can be both niche and an important milestone. |
If you check the search results, many of them are either written or updated within the last two years.
If that's really the case, why would it matter how we run the loose scripts by default? The frameworks should take care of this for them and how the entry point is interpreted by default is the last thing they need to care about. This is also contradicting what the OP says:
Either most users get started by running a loose script and need to configure something to make it run as ESM by default, or they get started by writing code using some framework and the configuration should be done by the framework. I very much doubt how many JavaScript tutorials would teach readers to run ESM code in Node.js without any extra configuration and let them assume that it would just work, but we have evidence that most top Node.js tutorials are still explicitly teaching people to write a CommonJS entry point and run it without any additional configuration. I don't think we should invalidate existing working tutorials to prioritize non-working tutorials that may or may not even exist. Following a tutorial and finding out that what it says can run does not actually run is much more frustrating than trying out code in an environmnet that the tutorials do not teach (because it's in fact not runnable) and finding out that it doesn't work. |
If you want to, you can make any conclusions you want from that survey data. You could look at the 65-35 split of users already using ESM and say that more than two-thirds of our users are already using ESM, why shouldn’t it be the default? Or you could look at the 35% and say but this is still a large group, too large to inconvenience, etc. I think one fair conclusion that can be drawn is that this data does prove that far and away our users are application developers. They may run some loose shell scripts, but by and large I think it’s safe to assume that the vast majority of our users are probably doing most of their Node development in apps with a
I think the framing of “widespread breakage” or “Would you accept a change that breaks” or “Would you accept other breakages” is very leading. Not all breaks are created equal. As @benjamingr wrote, there’s a big difference between adding Every breaking change, like any change, has costs and benefits. The question for us is whether the benefits of this one outweigh its costs. I think they do: I think it really matters that Node join the rest of the ecosystem in prioritizing the standard module format, that we provide the best experience for users in that mode, and that we make it easier to write standards-compliant JavaScript. I think the requirement of a one-line JSON file change, or adding a flag, is a very minimal cost to impose on a minority of users in order to realize these benefits.
Well then that would imply that they’re still maintained, and if we announce that this change is coming, they’ll be updated before April 2024. Regardless, we can add a link to our own tutorial in the error message that someone would get when they run CommonJS syntax in ESM mode. I don’t view this as a blocker. |
I don't think "we are not going to do a large-scale survey" is a good response for the lack of data to support an important breakage like this. If we can't run a survey anytime soon, then we should wait until we are ready to run another survey, gather data about how breaking the breakages are, before we make a decision to break something that's been working for more than 10 years and in most top Node.js tutorials out there.
If the weight of this breakage is enough in the prioritization, then it should be a very commonly used thing that would break a lot of people, hence a huge cost. If it only breaks a minority of users, then it should not have much weight in the prioritization and it's not really worth breaking. I don't think it can only have a minimal cost while also bring a lot of weight in the migration. |
I think this is a blocker. We need to at least make sure that the top Node.js tutorials out there are teaching people to write ESM by default before we create a sense of emergency, and for example, >90% of our users are ready for the flip. If that doesn't happen, then we should postpone the flip. It's fine to announce that a change is coming, but I think a one-year notice is just too short for breaking something that's been working and assumed everywhere for more than 10 years. |
I think what you’re saying is that this is a big deal because it affects so many users; up to a third of our user base. What I’m saying is that it’s a small deal because all it takes is a minute of effort on those users’ part to update their projects to work in the new mode. Both things are true. If there’s a way to run another survey, sure, that would be great. @mhdawson? But I think we need to write the 21 announcement soon, so I find it hard to imagine we’ll have results in time to inform what we write. Even if we wanted to I don’t think we can promise anything in particular, because no one can predict what PRs get blocked, but I think we can say that we intend to propose flipping the default of |
I think "we'll flip in 22" is a message that shows how little we care about the stability of this software. This is not a niche API that only a fraction of users know about. It's something that has been working and assumed everywhere for more than 10 years, and it's something that almost all Node.js beginner tutorials out there has been teaching. A one-year notice for that is just too hasty. The message we should give is that "we'll flip when there's sufficient evidence that less than X percent of our users would be affected by the breakage" and ideally send a survey gathering data about the breakage (basically, "if you run the Node.js code you publish or maintain with |
This kind of statement has no acknowledgement that we’re just changing a default configuration setting, and that it’s easy to continue working in the previous mode if desired. I read phrases like “affected by the breakage” as implying that affected users are just irreparably broken, like they can never upgrade. This is not that. It does imply that we strongly prefer stability and backward compatibility, which we do, and I think that’s one of Node’s strengths. But a statement that says that we need to wait years to catch up with the ecosystem, to embrace a standard that was released in 2015, makes Node seem hopelessly stagnant and stuck in the past. I’d like to think that we’re a more forward-looking and faster-moving project than that. I think we can draft a statement along the lines of this:
|
Even browsers do not support
I would say this statement only looks appropriate when the flag is no longer experimental. It still looks careless to release a timeline for such a widespread breakage based on an experimental feature that just gets out and is not yet even tested in the wild. |
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 `@@​toStringTag` property descriptors on DOM collections, [#​1312](https://github.com/zloirock/core-js/issues/1312) - Fixed the order of arguments validation in `Array` iteration methods, [#​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, [#​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, [#​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, [#​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 `core-js@3.32.1` bug, [#​1288](https://github.com/zloirock/core-js/issues/1288) - Added a workaround of old WebKit + `eval` bug, [#​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, [#​1279](https://github.com/zloirock/core-js/issues/1279), thanks [**@​petamoriken**](https://github.com/petamoriken) - Prevented injection `process` polyfill to `core-js` via some bundlers or `esm.sh`, [#​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 `[@@​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, [#​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), [#​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, [#​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, [#​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`, [#​1235](https://github.com/zloirock/core-js/issues/1235), thanks [**@​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, [#​1242](https://github.com/zloirock/core-js/issues/1242) - Added a workaround for getting proper global object in Figma plugins, [#​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, [#​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, [#​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, [#​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[@​@​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[@​@​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 `@@​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[@​@​dispose]` - `AsyncDisposableStack` - `AsyncDisposableStack.prototype.disposeAsync` - `AsyncDisposableStack.prototype.use` - `AsyncDisposableStack.prototype.adopt` - `AsyncDisposableStack.prototype.defer` - `AsyncDisposableStack.prototype.move` - `AsyncDisposableStack.prototype[@​@​asyncDispose]` - `Iterator.prototype[@​@​dispose]` - `AsyncIterator.prototype[@​@​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 `@@​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, [#​1154](https://github.com/zloirock/core-js/issues/1154), [#​1155](https://github.com/zloirock/core-js/issues/1155), thanks [@​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`, [#​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 [#​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), [#​1118](https://github.com/zloirock/core-js/issues/1118) - Added `inverse` option to `core-js-compat`, [#​1119](https://github.com/zloirock/core-js/issues/1119) - Added `format` option to `core-js-builder`, [#​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, [#​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, [#​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, [#​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`, [#​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 [#​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`, [#​1110](https://github.com/zloirock/core-js/issues/1110) - Fixed detection of `@@​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), [#​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, [#​1103](https://github.com/zloirock/core-js/issues/1103) - Hermes (`hermes`), compat data for 0.1-0.11, [#​1099](https://github.com/zloirock/core-js/issues/1099) - Oculus Browser (`oculus`), compat data mapping for 3.0-22.0, [#​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, [#​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, [#​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, [#​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, [#​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 [#​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, [#​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, [#​1061](https://github.com/zloirock/core-js/issues/1061) - `null` and `undefined` allowed as the second argument of `structuredClone`, [#​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`, [#​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…
Now that nodejs/node#49869 has landed, and we need to figure out what to say about it for the 21.0.0 announcement, we should agree on a tentative plan for when the default value of
--default-type
flips fromcommonjs
tomodule
. That would be a semver-major change.Obviously we can’t announce a certain date or version, since we don’t know what issues may arise during 21.x as people test out
--experimental-default-type=module
and when we might consider it stable, but assuming things go fairly smoothly then we could conceivably make the flip in 22.0.0 in April 2024. I think that would probably be preferable to 23.0.0 in October 2024, which would mean that the first LTS line with ESM by default wouldn’t begin until 24.x in April 2025, which is a long way off.I think for the health of the project and the greater JavaScript ecosystem it’s important for Node.js to shift to an ESM-first mindset. We will continue to support CommonJS as a first-class module system, but it becomes opt-in rather than opt-out, conforming Node with other runtimes and modern tools.
This is primarily a change for new users. Most users learning JavaScript today are learning it with
import
/export
syntax and get frustrated when Node doesn’t run their code right away without messing with configuration settings. I think it’s important that we prioritize the UX of these users. The users still writing CommonJS today are among our most sophisticated and experienced, and will be able to figure out how to opt into the old mode via--default-type
or the"type"
field.The text was updated successfully, but these errors were encountered: