cypress: Possible type definition conflict on @types/chai

Confirmed, it was skipLibCheck I added to get around Jest “Set” problem. Ok, so the recommended solution is ultimately

{
  "compilerOptions": {
    "skipLibCheck": true
  }
}

in the root tsconfig.json file. Not ideal, but it is hard or impossible to make globals work without clashing.

why not make @types/mocha a peer dependency or optional dependency? I have cypress and jest, and a third tool that has nothing to do with either but is using typescript and it’s picking up on the fact that both are installed.

None of the solutions which @Vheissu described were working for me, including their last one. The thing that finally got my project working was adding the include tag:

{
  "compilerOptions": {
    ...
  },
  "include": [
    "./node_modules/@types/jest"
  ],
  ...
}

Not sure why none of the other solutions didn’t work for my project, but just thought I would put this here in case somebody else is having this issue as well.

I just got bitten by this…

I have Jest for unit tests written in TypeScript, and I just added in Cypress but have my Cypress tests kept as the default .js my Cypress tests work beautifully, however my Jest tests are now throwing errors like Property 'toBeCalled' does not exist on type 'Assertion'. Property 'toEqual' does not exist on type 'Assertion'. Did you mean 'equal'? and a few others.

I have tried everything listed in this issue as well as other issues and repos:

• Two separate tsconfig.json files
• skipLibCheck to true (it was already true)
• Setting types in my root tsconfig.json to be an empty array
• Adding /// <reference types="Jest" /> to the top of my Jest unit tests
• Changing the include paths in my root tsconfig.json file

This is a serious issue and it should be reopened @bahmutov

I was able to fix this by doing the following:

{
  "compilerOptions": {
    "types": [],
    "skipLibCheck": true,
    "paths": {
      "chai": ["./noop.d.ts"]
    }
  }
}

In the root you need to create an empty file called noop.d.ts mentioned in the path above.

Super not ideal, but it got me out of a bind short of not using Cypress at all.

Yet another fix, in case someone finds it useful.

I had confict issues with global types. In my case, I was using Angular (v8), which uses jasmine and karma by default, and I added Cypress (v3.6.1).

The issue I had was that after installing Cypress, suddenly my Angular specs started complaining because the expect() type was coming from chai instead of jasmine.

My (hacky) fix was adding this to the main tsconfig.json file.

{
    (...)
    "include": [
        "src",
        "node_modules/cypress"
    ],
    "exclude": [
        "node_modules/cypress"
    ]
    (...)
}

I did that because you can only exclude what has been included.

The issue specifically reappeared after latest update to 4.4.1, is there any change that could have affected this? Will try to produce a repro later. Edit: adding cypress to excluded folders of my global tsconfig did the job. But I am not sure why the issue appeared suddenly, there might be an underlying root cause.

I have done some experimentation. Here’s what works:

./tsconfig.json

{
  /* ... */
  "types" : ["mocha"] // or "jest" or any other global module your project needs.
  /* ... */
}

./cypress/tsconfig.json

{
  "extends": "../tsconfig",
  "compilerOptions": {
    "baseUrl": "../node_modules" // needed if your tests import npm modules
  },
  "include": [
    "../node_modules/cypress/types",
    "**/*.ts"
  ]
}

Cypress seems to handle TypeScript just fine without any extra configuration, so the cypress/tsconfig.json is just to keep the editor happy.

We are trying to move all @types definitions into our bundle, so this work is done in https://github.com/cypress-io/cypress/pull/3425

It’s sad that this has no universal fix. Tried all the solutions and none worked

This PR will likely fix these issues without needing the workaround https://github.com/cypress-io/cypress/pull/3425

I think the issue is deeper than just conflicts in chai. The conflict can happen for any type definition declared on global (jest, mocha, chai, jquery, etc). The issue is Cypress is basically its own environment. The good news is Cypress is meant to run in its own subdirectory of a project (it could be in its own repo, but I like it in the source project).

I think the solution for TypeScript users should be to have their own tsconfig.json where you can set up a more limited environment. I’m experimenting with that right now. It would be good to put these best practices in the TypeScript example with some explanation as to why. If people use that example as a starting point, it will reduce the likelihood that someone will run into this issue.

Proposal: The idea is you have a tsconfig.json in the cypress folder. This tsconfig.json extends from the tsconfig.json in the base of the project. It has a baseUrl that references the project base path (most likely ../node_modules). It has a typeRoots that picks ../node_modules/cypress/types before ../node_modules/@types to ensure Cypress gets resolved first. Maybe include manually references ../node_modules/cypress/types as well.

I’ll try this out and post back.

Why is this issue closed? Doesn’t feel like it’s solved, at all.

Hi, can we make this a bit more alive? I see this as big issue and moving mocha to peer dependency as the best option - i just spent non-trivial time now to define the types in app tsconfig, this can introduce issues in the future as project (and number of people) grows. skipLibCheck is really brutal option -> if you have bigger projects, this really becomes handy.

@kirjai You are right that separating types puts some burden on developers. The upside is types only needs to be specified for files with global declarations. Also a way around this when using bundlers is to simply import 'jest' in a spec helper (that will grab the type definitions regardless of types setting in tsconfig.json - easier to maintain possibly?)

From https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#types-typeroots-and-types

Keep in mind that automatic inclusion is only important if you’re using files with global declarations (as opposed to files declared as modules). If you use an import “foo” statement, for instance, TypeScript may still look through node_modules & node_modules/@types folders to find the foo package.

I don’t think there is an ideal solution. Cypress uses globals for convenience (no import statements are required) and projects can also have globals for various reasons (legacy or otherwise). The possibility of global conflicts is the reason why modules was introduced. I think documentation can note possible solutions with tradeoffs. Disabling lib checks can have issues as well:

Since declarations in one file can affect type checking in other files, some errors may not be detected when --skipLibCheck is specified. For example, if a non-declaration file augments a type declared in a declaration file, errors may result that are only reported when the declaration file is checked. However, in practice such situations are rare.

I think skipping lib checks is the easiest solution with the least overhead. It also solves issues like chai-enzyme and chai-jquery have conflicting overrides for chai (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/22173). I hesitate to recommend something that disables type checks, but I understand this use-case. I tend to fix the root issue, but that can take a lot more time and effort.

Adding "types": ["@types/jest", "cypress"] in this specific order fixed the problem for me.

@Vheissu You did a lot of things that should work. Be sure to restart your TS language service after each change as it is sometimes not picked up. In VS Code it is “Restart TS” something in the command palette.

This is a hard problem and I’m glad the Cypress team is working to fix the issue and reduce the developer setup burden.