Nx: Generate complete jest config for angular libraries

Created on 3 Apr 2020  路  12Comments  路  Source: nrwl/nx

Expected Behavior

When generating a new angular library, a complete jest.config.js file should be generated, including everything needed for jest-preset-angular.

This would allow using the jest CLI directly which has a few benefits:

  • easier integration of vscode-jest
  • ability to run a single unit test file without specifying the library first
  • ability to run all unit tests in one go

Current Behavior

The jest.config.js does not include all necessary config properties required to run the tests. Instead, those are patched by the nx jest builder, preventing configuration by the user.

Steps to Reproduce

  1. Create nx workspace
  2. Generate a new angular library
  3. Try to run unit tests using the Jest CLI (cd <path_to_library_root> && jest)
  4. See failing tests

Solution

I would solve this by renaming skipSerializers to something like useAngularPreset, controlling all required properties for jest-preset-angular.

I'm happy to do a PR for this if that's the way to go.

Related

2768

2377

2314

1506

1091

testing tools

Most helpful comment

@wrslatz @jeserkin I just wanted to add the solution we are using to run tests using VSCode-Jest. This issue is somewhat of a requirement for it though (at least without touching generated libs), as all libs must have a working jest config.

I've uploaded the script on gist: https://gist.github.com/FERNman/14e3fe4086d6040cbb1f8e6174c9f0c6

What it does is pretty much a simplified version of nx affected:test combined with the Jest CLI. For some jest parameters (mainly arrays), the method parseJestArgs must probably be adapted.

Also, it may require maintenance from time to time if the nx workspace interface changes, but that should not happen too often.

All 12 comments

As members of the project are being silent, I would just recommend going with PR 馃槈

This might help with https://github.com/nrwl/nx/issues/2344.

We're having a difficult time running jest tests consistently in both the IDE and CLI due to the fact that most jest IDE runners can only look at a single jest.config.js (see my comments on #2344 as an example of config clashing between root and lib level jest configs trying to keep both the IDE and CLI happy)

I managed to write root level jest.config, that supports both.

https://gist.github.com/jeserkin/2e417326418cde2b06bd97dbb79a3ec2

But Debugging with use of breakpoints is not working for me in IDE and I am not sure if it is related to jest setup or not.

@wrslatz if you need to run tests for both your app and your project libs, then easiest wat, that I found was to just make a custom script in package.json and that is it.

npm run test:app-related ->
"ng test app && ng test lib1 && ng test lib2 && ng test lib3 && ng test lib4" etc.

@jeserkin I saw your config on one of those other issues, definitely an improvement!

We are getting around it right now by

  • having all jest.config.js, both root and in each app / lib, have setupFilesAfterEnv: ['<rootDir>/test-setup.ts']
  • changing the root setupJest.ts name to test-setup.ts
  • moving test-setup.ts out of /src in all apps / libs (and adjust all references) so that the setupFilesAfterEnv that is passed via Nx jest builder's setupFile option matches the root jest.config.js

This works, but is less than optimal for the following reasons:

  • newly generated apps / libs are broken from the start, which is a poor experience for new users or teams
  • the error related to this config being messed up can be hard to understand or troubleshoot for newcomers
  • the IDE jest runners don't seem capable of running with multiple jest configs, meaning the root test-setup.ts file needs to support setup for all libraries and may cause unnecessary overhead across apps / libs

tl;dr it works but we lose some of the benefits of Nx along the way, making for a poorer experience

@wrslatz @jeserkin I just wanted to add the solution we are using to run tests using VSCode-Jest. This issue is somewhat of a requirement for it though (at least without touching generated libs), as all libs must have a working jest config.

I've uploaded the script on gist: https://gist.github.com/FERNman/14e3fe4086d6040cbb1f8e6174c9f0c6

What it does is pretty much a simplified version of nx affected:test combined with the Jest CLI. For some jest parameters (mainly arrays), the method parseJestArgs must probably be adapted.

Also, it may require maintenance from time to time if the nx workspace interface changes, but that should not happen too often.

Thanks @FERNman for passing this along! I'll give it a shot

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nrwl community! 馃檹

We are still experiencing this issue in our Nx monorepo

Sorry. The issue was marked by mistake. I removed the label.

@vsavkin no worries, I saw the new stale automation got put in place so figured it's related. My comment was simply to bump the discussion.

@wrslatz @jeserkin I just wanted to add the solution we are using to run tests using VSCode-Jest. This issue is somewhat of a requirement for it though (at least without touching generated libs), as all libs must have a working jest config.

I've uploaded the script on gist: https://gist.github.com/FERNman/14e3fe4086d6040cbb1f8e6174c9f0c6

What it does is pretty much a simplified version of nx affected:test combined with the Jest CLI. For some jest parameters (mainly arrays), the method parseJestArgs must probably be adapted.

Also, it may require maintenance from time to time if the nx workspace interface changes, but that should not happen too often.

May I ask what is next? I can have this file in root, but I am not sure how to use it

May I ask what is next? I can have this file in root, but I am not sure how to use it

Compile the script and set the Path to Jest for vscode-jest to node dist/scripts/run-all-tests.js (or whatever the path of the compiled script is).

Was this page helpful?
0 / 5 - 0 ratings