nx: Editors are unable to properly locate types for spec files

Still same problem using Jasmine + Cypress in VS Code. : Property 'toBeTruthy' does not exist on type 'Assertion'., Any workaround?

Adding an exclude works, in my root tsconfig.json I have:

,
  "exclude": [
    "e2e"
  ]

Thanks ! I’ll open a PR to cypress doc to document this.

Hi all,

So we’ve been looking into and discussing this issue. Thank you for all the debugging in this thread.

I would like to generalize this issue to encompass https://github.com/nrwl/nx/issues/892 as well.

@skydever Was correct with the two typescript issues.

There are two ways to fix and could (but not necessarily) involve some significant changes to the workspace.

Basically, the constraints are the following:

1. Jest, Jasmine, and Chai (through cypress) all define global typings (expect, describe, it) which conflict with each other a. The only way to workaround here is to delete the typings you do not want. b. This is most likely not the approach we want to take here
2. VSCode (tsserver) uses the next highest tsconfig.json to provide intellisense in a .ts file. a. One fix for this, we could generate a tsconfig.json along with tsconfig.app.json/tsconfig.lib.json/tsconfig.e2e.json and tsconfig.spec.json. That file would only be used by the editor and not targetted by any tools. However, I realize that is a lot of configuration. b. The other option is to use /// <reference types="..." at the top of each file. This is a more granular approach and basically allows using specified types in the particular file. This would have to be added to every file (possibly even application code). We could generate this based on the project where code is being generated but you would have to maintain this when manually creating files (jest projects get a reference to jest types, karma projects get references to jasmine types).

We have seen large monorepos use both solutions and are not sure which one to go with for the Nx workspace. You can use either one of the “fixes” above as you wish. We would like to hear what the community thinks is a better fix.

@FrozenPandaz What about the workaround of adding import 'jest'; to test-setup.ts? I seems to do the job and I haven’t seen any side effects.

of course, you should not use protractor either. use cypress for that ^^

you need to uninstall jasmine and @types/jasmine to have correct type in your IDE. or specify the types config in tsconfig.json to include jest

@AltarBeastiful I excluded the cypress folder from the root tsconfig.json file and that fixed it for me

Adding an exclude works, in my root tsconfig.json I have:

,
  "exclude": [
    "e2e"
  ]

Thanks ! I’ll open a PR to cypress doc to document this.

For those of you trying out this solution, I also had to add exclude: [] to my /e2e/tsconfig.json, or VSC could not resolve the Cypress namespace after restarting VSC (Even restarting the TS server does not show the error).

Adding import "cypress" in app/myapp-e2e/src/support/index.ts did the trick for me with phpstorm 🥳

Does it work for anyone else ?

@FrozenPandaz What about the workaround of adding import 'jest'; to test-setup.ts? I seems to do the job and I haven’t seen any side effects.

This is interesting. Do you know how this works?

There are projects which will not have the test-setup.ts because it does not require it.

Adding test-setup.ts to the projects which required jest and adding import 'jest'; to test-setup.ts fixed the problem for me. My guess when we import 'jest', typescript use functions in jest module in all the test files, the vscode then see those types correctly.

This is a nightmare.

@Stronhold did you include a tsconfig.json file inside your cypress folder? https://docs.cypress.io/guides/tooling/typescript-support.html#Configure-tsconfig-json

@danielgeri @Stronhold I’m having the same issue. I included the tsconfig in the cypress folder but still get Property 'toBeTruthy' does not exist on type 'Assertion' Any solution?

tsconfig inside cypress folder will affect cypres spec files but not existing files for karma unit tests. Because of that I am tinking about creating separate “child” project for cypress only and isolate it with typings so that it cannot affect existing unit test files. Only con is slightly different scripts for cypress open and run from parent project.

We’ve discussed this issue and the better solution seems to be adding tsconfig.json files to each project root.

Adding /// <reference to all spec files is tedious and is too granular as the builders target the whole project.

I will also be writing a page for this in the wiki to explain more. (Link TBD)