I've actually solved the issue for myself but wanted to raise this in case others had the same issue.
Sorry if this is just creating noise for the team. Is there be a better way to document these kind of things in the future?
What did you expect to happen?
After reading the migration guide and the docs I expected everything to carry on working as I wasn't using any removed functionality.
What actually happens
Several tests failed with the error HTMLElement is not defined.
ReferenceError: HTMLElement is not defined
at typeDetect (node_modules/sinon/node_modules/type-detect/index.js:159:24)
at typeOf (node_modules/sinon/lib/sinon/util/core/typeOf.js:6:12)
at match (node_modules/sinon/lib/sinon/match.js:103:16)
at node_modules/sinon/lib/sinon/call.js:50:43
at Array.reduce (native)
at Object.calledWithMatch (node_modules/sinon/lib/sinon/call.js:47:36)
at Function.spyApi.(anonymous function) [as calledWithMatch] (node_modules/sinon/lib/sinon/spy.js:372:47)
at Assertion.<anonymous> (node_modules/sinon-chai/lib/sinon-chai.js:95:48)
at Assertion.ctx.(anonymous function) [as calledWithMatch] (node_modules/chai/lib/chai/utils/addMethod.js:41:25)
My solution
I need a DOM to test some of our React components so the type-detect module was entering the isDom block and then failing. I was able to fix this by adding the following to the script that creates the virtual DOM for my tests:
global.HTMLElement = () => {
}
Note: This wasn't an issue in 1.x and I haven't done any investigation as to what changed in 2.x to result in this issue.
I am also seeing this issue since upgrading to 2.1.0. I also see it on 2.0.0.
Downgrading to 1.17.7 fixes the issue.
Also seeing the same thing, but we're running our tests in Node using Ava.
I also encountered a similar error as @GentlemanHal
ReferenceError: HTMLElement is not defined
at typeDetect (node_modules/sinon/node_modules/type-detect/index.js:159:24)
at typeOf (node_modules/sinon/lib/sinon/util/core/typeOf.js:6:12)
at match (node_modules/sinon/lib/sinon/match.js:103:16)
at node_modules/sinon/lib/sinon/call.js:50:43
at Array.reduce (native)
at Object.calledWithMatch (node_modules/sinon/lib/sinon/call.js:47:36)
at Function.spyApi.(anonymous function) [as calledWithMatch] (node_modules/sinon/lib/sinon/spy.js:372:47)
at .<anonymous> (node_modules/sinon-chai/lib/sinon-chai.js:95:48)
at ctx.(anonymous function) (node_modules/chai/lib/chai/utils/addMethod.js:41:25)
at doAsserterAsyncAndAddThen (node_modules/chai-as-promised/lib/chai-as-promised.js:293:29)
at .<anonymous> (node_modules/chai-as-promised/lib/chai-as-promised.js:252:17)
at ctx.(anonymous function) [as calledWithMatch] (node_modules/chai/lib/chai/utils/overwriteMethod.js:49:33)
at Context.<anonymous> (spec/javascripts/shared/apiFetch-test.js:125:40)
As a workaround I used global.HTMLElement = function() {}; in my mocha setup.js file.
I've experienced the same issue, but setting the HTMLElement to a noop did not solve all problems. Setting it to the value from the jsdom window as suggested on this type-detect issue did, though.
My setup includes populating global from the jsdom window prior to executing tests (a somewhat common setup, I believe). I was previously just enumerating the enumerable properties of the window (via Object.keys), but that misses DOM interfaces that are added as non-enumerable. Also, it seems to be the case that running via a VM context makes Object.getOwnPropertyNames return values that are associated with the new global context object rather than the original window (while still preserving the actual properties themselves).
import { jsdom } from 'jsdom';
const document = jsdom('');
// properties must be extracted from a document that was created that does not
// use a vm context.
const properties = Object.getOwnPropertyNames(
jsdom('', { features: { ProcessExternalResources: false } }).defaultView
);
properties.forEach((property: string) => {
if (typeof global[property] === 'undefined') {
global[property] = document.defaultView[property];
}
});
Oh, also, this should probably be closed since it does seem to be a type-detect issue.
Closing this. Thank you all for contributions :)
@mroderick should we close this before we have upgraded our dependencies? not that the issue is with us, but we are still affected by it.
If you are suffering from this error, here is a clean way to solve it across all tests
// create a file called sinon-fix.js in your root test directory that has this line in it
global.HTMLElement = () => {};
// add a reference to sinon-fix in your global mocha.opts file
--require test/sinon-fix.js
A PR for type-detect resolves this issue. We are just waiting for a new version of type-detect to land on npm, and I can publish a new Sinon release
@chaijs/type-detect v4.0.5 just got released.
I think you can fix this now
@mroderick No point in pushing a new version of Sinon. It won't fix anything for consumers. This is automatically fixed by npm install, as we use loose versioning, and the caret in type-detect's ^4.0.0 version includes all patch and minor revisions. We could still push a commit that updates the version number for consistency (and updating the package-lock.json, which locks our development version to the buggy one).
To me, this issue should just be closed.
Most helpful comment
I also encountered a similar error as @GentlemanHal
As a workaround I used
global.HTMLElement = function() {};in my mochasetup.jsfile.