Angular-builders: Option to disable global-mocks on jest builder

Created on 15 Mar 2020  路  15Comments  路  Source: just-jeb/angular-builders

Describe the Bug

I'm having problems with the global mocks configured, I would like to disable them. Could be posible to provide an option in angular.json to disable it?

Minimal Reproduction

I think it isn't needed

Expected Behavior

And option to disable the mocks applied

Screenshots

If applicable, add screenshots to help explain your problem.

Environment


Libs

  • @angular/core version: latest
  • @angular-devkit/build-angular version: latest
  • @angular-builders/jest version: latest

For Tooling issues:
I think it isn't needed

Others:
None

Additional Context

Add any other context about the problem here.

jest enhancement

Most helpful comment

Just to add to this, I was running into some trouble using @testing-library/angular and its accessibility selectors. The getComputedStyle mock seems to to interfere with discoverability of accessible elements.

All 15 comments

You don't need a special option for this. The global mocks can be easily overwritten if you add your own setup file to setupFilesAfterEnv and in this file redefine the window props.

I have my own setup file with setupFilesAfterEnv, but they are not being overwritten, I think they are concatenated.

And how global-mocks override global properties before my setup runs, I can not do anything to avoid it

The setup files array is concatenated, you're right, but that only means that the setup files run in order one after another. Which means if you redefine window properties in your setup file they should get overwritten even if the default setup file defined them before.

The setup files array is concatenated, you're right, but that only means that the setup files run in order one after another. Which means if you redefine window properties in your setup file they should get overwritten even if the default setup file defined them before.

That's exactly what I want to do, but I want to avoid the redefinetion of window's properties. I don't want to patch window and leave it as it's (prev to global-mocks.ts applied). I want this behavior because actually some patches are not necessary anymore...

Well if some of the patches are not necessary anymore we probably should change it in the builder. Let's discuss.

Ok, here you have a list of patches that I think don't be necessary anymore:

  • this patch ==> *storage are full implemented
  • this patch ==> I don't know why this patch is currently necessary, I think js-dom has doctype full implemented
  • this patch ==> getComputedStyle and why I opened this issue (because its value breaks me some tests that use it) is mostly well-supported

Those are the patches I think could be removed, what do you think?

The storage included in JsDom >= 11.12.0 works perfectly. The mock just broke the readonly property "length" (always undefined).

Jest 24 (which is the minimal version to use with this builder) uses jsdom@^11.5.1.

Thus:

  • localStorage - implemented since 11.12.0 - mock removal might break some builds that explicitly depend on [email protected] but shouldn't break builds that just depend on Jest 24.
  • sessionStorage - same as localStorage.
  • document.doctype - couldn't find any mention of that in JSDOM. The only thing I found is that doctype is serializable but I'm not sure whether it works or not as a document property.
  • getComputedStyle - started being relatively similar to the native implementation since 15.2.0 - the mock cannot be removed before we move to Jest 25 as a minimal required version (Jest 25 uses jsdom@^15.1.1).
  • transform property - has been implemented in [email protected] which is being used by jsdom. However [email protected] explicitly requires cssstyle < 0.3.0. [email protected] uses cssstyle@^1.0.0. Therefore again, mock removal might break some builds that explicitly depend on [email protected] but shouldn't break builds that just depend on Jest 24.
  • matchMedia - not implemented in jsdom, official Jest documentation suggests to mock it.

Conclusions:
I don't think we can remove the mocks as part of a minor release, IMHO they should be all removed as part of version 10 which should require Jest 25.
What we can do until then in order to address your specific issues is:

  1. Fix the mock where applicable (like length undefined in storage)
  2. You can redefine the global mock to fit your specific test case like in case of getComputedStyles.

What do you think?

Thanks for the extensive well-documented response @just-jeb!! :clap:

I understand that mocks can't be removed yet, I'm ok with that.

However, my main problem persists because I can't simply redefine the mock (I don't want to mock it, just leave it as it is, without mock), I need the original behavior of getComputedStyles implmeneted injsdom, before it has been mocked.

As my setup-file always runs after your global-mocks I can't avoid the mock to happens or restore the original getComputedStyles.

For that reason,

Could be posible to provide an option in angular.json to disable it?

Then, I could disable your global-mocks and applied the mocks that I really need.

As a workaround (if anyone want to be able of disable the global-mocks) I'm using this script in my package.json to remove the mocks:

"scripts": {
  "postinstall": "echo > node_modules/@angular-builders/jest/dist/jest-config/global-mocks.js"
}

I would prefer to have an option, but this works meanwhile :+1:

Thanks @tonivj5 . Just FYI you're not forgotten, I have a proper solution in mind just need to find time to implement it.

Thanks for the feedback :rocket:

Just to add to this, I was running into some trouble using @testing-library/angular and its accessibility selectors. The getComputedStyle mock seems to to interfere with discoverability of accessible elements.

Hey, @klinem thanks for the report and sorry for the late response.
Seems like we still need the option to disable the global mocks.

The new globalMocks option is available in v11.2.0-beta.0, please confirm it works for you.
For more details refer to documentation.

Was this page helpful?
0 / 5 - 0 ratings