Jest: Hide JSDOM "not implemented" errors

[Aftabnack]

Do you want to request a _feature_ or report a _bug_?
_feature_

What is the current behavior?

• All of the jsdomError's are directly thrown as-is onto the console.

What is the expected behavior?

• I would prefer suppressing all of these warnings by passing { omitJSDOMErrors: true } as mentioned in JSDOM docs

https://github.com/facebook/jest/blob/398a238f841ebf6b4535d95d93b89f9c3f673ff9/packages/jest-environment-jsdom/src/index.js#L34-L36

Please provide your exact Jest configuration and mention your Jest, node,
yarn/npm version and operating system.

• Node: 8.6.0
• Jest: 22.0.5

[SimenB]

See closed PR

[Aftabnack]

• If anyone is coming here with the same issue, I have made a separate package that you can use as a drop-in replacement for jsdom: jest-env-jsdom-silent. Read the thread here

[montogeek]

@SimenB Why it is ok to silent thore errors? I think the test run should fail is there is an error.

[SimenB]

@montogeek we don't silence anything. And there is nothing failing, it's warnings in the console. We don't fail on invocations to console.error either, and I think such behavior would be really weird.

[montogeek]

No Jest, I mean from a developer view they should throw the tests. Those are errors (https://github.com/jsdom/jsdom/blob/master/lib/jsdom/browser/not-implemented.js#L9), not warnings.

Don't you think Jest should throw them as well? Or it is a limitation on JSDom? It is using a virtual console, not sure what it means.

[SimenB]

I'm not sure if it makes sense to fail on that, or other, errors. Maybe it does? We could do omitJSDOMErrors: true and actually fail the tests if we get them (behind an option).

But what if people want to throw if there are unimplemented things, but not for css parsing errors or other things?

/cc @kentcdodds thoughts?

[Aftabnack]

But what if people want to throw if there are unimplemented things, but not for css parsing errors or other things?

Even if we want to do this, this level of granularity, if not exposed by jsdom, we cannot do anything about it right?

[SimenB]

No issue for us to check type property, for instance, and either just log or throw it.

That's not to say I think we should do this (or not), just saying it's possible

[montogeek]

It took me by surprise last week, when after upgrading Jest I saw the error in the console but tests passed anyway, it was, counterintuitive for a test runner to don't throw when there is an error.

Activating omitJSDOMErrors is not a good idea:

There is even an omitJSDOMErrors option to do this for you, although that will suppress all error logging (e.g. uncaught runtime exception), not just CSS ones.

https://github.com/jsdom/jsdom/issues/2026#issuecomment-339078997

[kentcdodds]

I recommend against changing anything. These are not throwing errors. They're simply console.error calls which is easily mockable if needed, but should be dealt with normally.

[kentcdodds]

In particular, the error in the screenshot indicates the user's code is trying to use an unimplemented feature in jsdom. You should either provide your own implemention or change your code. Without the error log, you would be unaware of this limitation and things could break in your app unexpectedly. Much worse situation.

[montogeek]

Those are actual errors, that are reported to a virtual console and outputted using console.error does not matter, it is an error and should be handled by Jest accordingly, the same way as expect(true).toBe(false) is reported.

This was reported and acknowledged as a bug in https://github.com/facebook/jest/issues/4400, looks like it was fixed on v22 but it is still ignoring them.

[kentcdodds]

Actually, I'd be fine with that change 👍