webidl upgrade broke API in 8.2.0

[matthughes]

I'm not at all a JS expert but after getting silently upgraded to 8.2.0 I'm seeing the following error in my build:

TypeError: Cannot read property 'some' of undefined
    at Object.exports.install (/Users/mhughe008/development/vise/node_modules/whatwg-url/dist/URL.js:84:20)
    at exports.installInterfaces (/Users/mhughe008/development/vise/node_modules/jsdom/lib/jsdom/living/interfaces.js:202:24)
    at setupWindow (/Users/mhughe008/development/vise/node_modules/jsdom/lib/jsdom/browser/Window.js:63:3)
    at new Window (/Users/mhughe008/development/vise/node_modules/jsdom/lib/jsdom/browser/Window.js:107:3)
    at exports.createWindow (/Users/mhughe008/development/vise/node_modules/jsdom/lib/jsdom/browser/Window.js:38:10)

Failing at this section of code:

exports.install = (globalObject, globalNames) => {
  if (!globalNames.some(globalName => exposed.has(globalName))) {
    return;
  }
  class URL {
    constructor(url) {
      if (arguments.length < 1) {

This is using jsdom 16.1.2. Best I can tell this was probably caused by the upgrade to webidl-conversions:

-    "webidl-conversions": "^5.0.0"
+    "webidl-conversions": "^6.1.0"

[domenic]

Can you test using jsdom 16.4.0?

[matthughes]

That does work. But:

1. Is there a reason jsdom still lists 16.2.2 as the "latest" release on GH? Is 16.4 legit?
2. Isn't this still a breaking API change that should be reserved for 9.x release?

[domenic]

1. Sorry for not updating the jsdom releases page; I did the changelog, but forgot to copy and paste there.

2. It's not clear. This is a change to an internal API used by jsdom only, and not a public API of the module. If I'd realized the consequences, maybe I would have done it differently, but I don't think it's worth re-spinning a release for. Especially since it only occurs for people who are somehow using outdated jsdoms but non-outdated whatwg-urls, which shouldn't really be happening?

[matthughes]

I don't pull in whatwg-url directly, I'm pulling it whatever jsdom says is compatible. jsdom 16.2.2 requires [8.x,9.x). Personally not a huge deal for me to upgrade but does seem like an API break.

[domenic]

Right, but, how did you manage to pull in an outdated version of jsdom?

I'll keep an eye on this; if more people report an issue then I'll release another patch version.

[matthughes]

What tool automatically pulls in the latest jsdom? My toolchain required a version.

[domenic]

Well, all dependents of jsdom I know of use ^ syntax when specifying a version, and don't pin exact ones. Do you have a link to one that specifies an exact version, and excludes bugfix updates?

[xmaysonnave]

I faced an issue with the recent upgrade of webidl-conversions": "^6.1.0 (whatwg-url 8.20 and 8.2.1)
I do not any issue with the previous dependency webidl-conversions": "^5.0.0 (whatwg-url 8.1.0)

This package explicitly use SharedArrayBuffer :
In webidl-conversions/lib/index.js line 347

const sabByteLengthGetter =
    Object.getOwnPropertyDescriptor(SharedArrayBuffer.prototype, "byteLength").get;

As a whatwg-url user I browserify/babel a library who uses whatwg-url and as a consequence the webidl-conversions lib/index.js is injected in the browserify/babel processed result.

With Firefox 79 and Firefox 80 the SharedArrayBuffer is not defined by default causing a crash.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
However the SharedArrayBuffer could be defined (tested) if the web server set and send correctly the two following headers :
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

However in my context (IPFS) I don't have any control over the public gateway servers http headers. This code should probably be revisited to detect whether or not the SharedArrayBuffer is available.

Let me know a more appropriate place to report this issue.

Thanks.

[domenic]

whatwg-url is only supported on Node.js.

[DanielVenturini]

whatwg-url@8.2.0 starts use the install method in dist/URL.js, as in this diff:

+exports.install = (globalObject, globalNames) => {
+  if (!globalNames.some(globalName => exposed.has(globalName))) {
+    return;
+  }

jsdom@<16.3.0 calls to install without the globalNames. jsdom@>=16.3.0 adds the globalNames when calls to whatwg-url, as in this diff:

// jsdom@16.3.0 lib/jsdom/living/interfaces.js
-exports.installInterfaces = window => {
+exports.installInterfaces = (window, globalNames) => {
   // Install generated interface.
   for (const generatedInterface of Object.values(generatedInterfaces)) {
-    generatedInterface.install(window);
+    generatedInterface.install(window, globalNames);
   }

For me, this error was fixed updating to jsdom@>=16.3.