Missing compatibility data for web.structured-clone

[wcauchois]

When I use the core-js-compat library to get information about web.structured-clone, it returns that it should always be polyfilled.

For example:

const compat = require('core-js-compat')
const result = compat({
  targets: 'Chrome > 110', 
  modules: [                 
    /structured-clone/
  ],
  exclude: [],
  version: '3.27.1',   
  inverse: false,
})
console.log(result)

outputs

{
  list: [ 'web.structured-clone' ],
  targets: { 'web.structured-clone': { chrome: '111' } }
}

I would expect it to not be in the list, since this feature is fairly widely supported and 110 is a recent version of Chrome.

I'm not super familiar with core-js internals but I dug a bit and I found this portion of some compatibility table which seems commented out:

core-js/packages/core-js-compat/src/data.mjs

Lines 2678 to 2684 in 3811821

	'web.structured-clone': {
	// https://github.com/whatwg/html/pull/5749
	// deno: '1.14',
	// current FF implementation can't clone errors
	// firefox: '94',
	// node: '17.0',
	},

is this a bug? And either way, would it be possible to correct the compatibility output in this case?

[zloirock]

It's not a bug in the compat data, it's implementations issues. For example, core-js relies on proper error cloning semantics, whatwg/html#5749, that's still not merged to the spec. It's missed in most engines, but available in some, like Firefox - but they have other issues. There were very many other issues in structuredClone / structured clone algorithm implementations, but most of them already fixed.

If the proper error cloning semantics will not be merged to the spec soon, most likely this requirement will be removed from the feature detection - but anyway not all actual implementations will be marked as proper.

[zloirock]

A little part of issues is documented in the source code, for example here:

core-js/packages/core-js/modules/web.structured-clone.js

Lines 79 to 108 in 6250ccb

	// FF94+, Safari 15.4+, Chrome 98+, NodeJS 17.0+, Deno 1.13+
	// FF<103 and Safari implementations can't clone errors
	// https://bugzilla.mozilla.org/show_bug.cgi?id=1556604
	// FF103 can clone errors, but `.stack` of clone is an empty string
	// https://bugzilla.mozilla.org/show_bug.cgi?id=1778762
	// FF104+ fixed it on usual errors, but not on DOMExceptions
	// https://bugzilla.mozilla.org/show_bug.cgi?id=1777321
	// Chrome <102 returns `null` if cloned object contains multiple references to one error
	// https://bugs.chromium.org/p/v8/issues/detail?id=12542
	// NodeJS implementation can't clone DOMExceptions
	// https://github.com/nodejs/node/issues/41038
	// only FF103+ supports new (html/5749) error cloning semantic
	var nativeStructuredClone = globalThis.structuredClone;
	var FORCED_REPLACEMENT = IS_PURE
	|| !checkErrorsCloning(nativeStructuredClone, Error)
	|| !checkErrorsCloning(nativeStructuredClone, DOMException)
	|| !checkNewErrorsCloningSemantic(nativeStructuredClone);
	// Chrome 82+, Safari 14.1+, Deno 1.11+
	// Chrome 78-81 implementation swaps `.name` and `.message` of cloned `DOMException`
	// Chrome returns `null` if cloned object contains multiple references to one error
	// Safari 14.1 implementation doesn't clone some `RegExp` flags, so requires a workaround
	// Safari implementation can't clone errors
	// Deno 1.2-1.10 implementations too naive
	// NodeJS 16.0+ does not have `PerformanceMark` constructor
	// NodeJS <17.2 structured cloning implementation from `performance.mark` is too naive
	// and can't clone, for example, `RegExp` or some boxed primitives
	// https://github.com/nodejs/node/issues/40840
	// no one of those implementations supports new (html/5749) error cloning semantic

[zloirock]

If structuredClone is available natively and incorrect only in some minor moments, in the polyfill it's just wrapped to fix those moments.