Skip to content
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

Upgrading to Sinon 2.1.0 resulted in "HTMLElement is not defined" error #1377

Closed
GentlemanHal opened this issue Apr 10, 2017 · 11 comments
Closed

Comments

@GentlemanHal
Copy link

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?

  • Sinon version: 2.1.0
  • Other libraries you are using: mocha, chai, sinon-chai, jsdom, react

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 = () => {
}

The commit with the upgrade.

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.

@ripter
Copy link

ripter commented Apr 11, 2017

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.

@jyboudreau
Copy link

Also seeing the same thing, but we're running our tests in Node using Ava.

@damenturnbull
Copy link

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.

@wbyoung
Copy link

wbyoung commented May 2, 2017

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];
  }
});

@wbyoung
Copy link

wbyoung commented May 2, 2017

Oh, also, this should probably be closed since it does seem to be a type-detect issue.

@mroderick
Copy link
Member

Closing this. Thank you all for contributions :)

@fatso83
Copy link
Contributor

fatso83 commented May 18, 2017

@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.

@hhowe29
Copy link

hhowe29 commented Oct 5, 2017

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

@mroderick
Copy link
Member

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

@vieiralucas
Copy link
Contributor

vieiralucas commented Nov 9, 2017

@chaijs/type-detect v4.0.5 just got released.
I think you can fix this now

@fatso83
Copy link
Contributor

fatso83 commented Nov 10, 2017

@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.

mroderick added a commit to mroderick/sinon that referenced this issue Nov 11, 2017
fatso83 pushed a commit that referenced this issue Nov 11, 2017
@fatso83 fatso83 closed this as completed Nov 11, 2017
franck-romano pushed a commit to franck-romano/sinon that referenced this issue Oct 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants