However, this is not only allows client scripts to escape the jsdom environment, it also fools brand checks if prototypes are used:
const url = new URL("...");
const notURL = Object.create(url);
console.log(notURL.href); // should throw TypeError but doesn't
On the other hand, private class properties are immune to this, due to their so-called WeakMap semantics. We could very well use the so-called "super-return trick" to implement IDL objects:
Private properties are supported since Node.js v12.x. They are supposed to be faster than WeakMap, but we should still do some performance investigations. (I expect it to be slower than symbol properties still.)
Oh I just recently saw this trick on Twitter and thought it might work for our object branding purposes. I was a bit worried about backwards compat, but node v12 sounds perfectly fine.
Right now, we implement wrapping/unwrapping of IDL objects through a symbol:
https://github.com/jsdom/webidl2js/blob/ab63e7e8ed59659dd961eef0ac0e56060db19870/lib/output/utils.js#L61-L77
However, this is not only allows client scripts to escape the jsdom environment, it also fools brand checks if prototypes are used:
On the other hand, private class properties are immune to this, due to their so-called WeakMap semantics. We could very well use the so-called "super-return trick" to implement IDL objects:
Private properties are supported since Node.js v12.x. They are supposed to be faster than WeakMap, but we should still do some performance investigations. (I expect it to be slower than symbol properties still.)