cypress: Cannot pick up typings for Cypress with the Typescript recipe

@ashnur I’ve noticed sometimes the Typescript server needs to be restarted (cache invalidation issue). You can do this by either from the command palette Cmd/Ctrl+Shift+P and type Restart Typescript server or restart VS Code.

One thing that helps a lot for JS and TS specs is adding a comment to manually tell where the cypress types are coming from

/// <reference types="cypress" />

At least in VSCode the types start working, here is IntelliSense when hovering over cy.visit

Adding /// <reference types="cypress" /> in top of every file solves the issue, playing around with tsconfig does not. For me maybe an extension messes up something.

No, having to install separate @types/cypress would be a huge pain. Most packages that have types just include them (like we do).

I’m just dropping into this thread, but - would it not be helpful to keep @types/cypress npm package published as this is the preferred way to handle types in TypeScript? It could help people who are struggling with hooking up the types from within Cypress’ install - I know it should be unnecessary for most though.

@guetar A duplicate identifier like the is probably because you use Chai in your project. Cypress is currently using @types/chai@4.0.8. If your project also uses @types/chai, but your version is incompatible with 4.0.8, your package manager (yarn or npm) will nest @types/chai under node_modules/cypress/node_modules - meaning you’ll have 2 versions of chai type definitions. Since it is a namespace (global), TypeScript will throw a duplicate identifier.

One of the solutions that worked well for me in this case (duplicate definitions) was to have a tsconfig.json inside the cypress folder that looked like this:

{
  "extends": "../tsconfig",
  "compilerOptions": {
    "baseUrl": "../node_modules",
    "target": "es5",
    "types": ["cypress"],
  },
  "include": [
    "**/*.ts"
  ]
}

The extends is useful if you have a base tsconfig.json. Without it, you’ll have to determine your own compiler options for the cypress directory.

A nuclear option would be to add skipLibCheck set to true which will disable TypeScript type checking inside lib files.

Here is what I use and I do not have to add /// <reference types="cypress" /> at the top of every file.

I have my custom typings under <projectroot>/cypress/support/index.d.ts

/// <reference types="cypress" />

declare namespace Cypress {
  interface Chainable<Subject> {
    getByDataTest(tag: string): Chainable<any>
  }
}

And my <projectroot>/cypress/tsconfig.json looks like

{
  "compilerOptions": {
    "strict": true,
    "baseUrl": "../node_modules",
    "target": "es5",
    "lib": ["es5", "dom"],
    "types": ["cypress"],
    "typeRoots": ["./support"]
  },
  "include": ["**/*.ts"]
}

And TypeScript is finally happy

describe('when I want to select by data test tag', () => {
  it('should select by data test tag', () => {
    cy.getByDataTest('yolo').should('exist')
  });
});

I have a tsconfig.json file in projectRoot/cypress/tsconfig.json as the example shows:

{
  "extends": "../tsconfig.json",
  "include": [
    "integration/*.ts",
    "support/*.ts",
    "../node_modules/cypress"
  ]
}

Does the tsconfig include Cypress?

I wonder if TypeScript compiler does not find types for some reason. Like it does not see the included files referenced from non-root tsconfig.json for example? I don’t know why that would be the case though.

  "include": [
    "../../node_modules/cypress",
    "cypress/*/*.ts"
  ]

Well, it seems that Vue.js does the same, includes types in core, but their configuration does not require defining types, baseUrl, includes. So, I’m just wondering what the discrepancy is? Why is ours so much more difficult to set up?

because for us the main things that cause problems

• global reference to cy which requires configuration (vs import vue from 'vue')
• conflicts with other global test things like Jest that also use expect and stuff like that 😦

Try adding "types": ["cypress"] to the tsconfig.json file under the Cypress directory. That worked for me. That should do the same thing as the reference directive @bahmutov suggested, but for all TS files.

@bahmutov aren’t your files in nested directories? If that’s the case, change this in include property cypress/**/*.ts.

Adding /// <reference types="cypress" /> in top of every file solves the issue, playing around with tsconfig does not. For me maybe an extension messes up something.

Simply adding /// <reference types="cypress" /> once in cypress/support/index.js made the tick for me.

@guetar A duplicate identifier like the is probably because you use Chai in your project. Cypress is currently using @types/chai@4.0.8. If your project also uses @types/chai, but your version is incompatible with 4.0.8, your package manager (yarn or npm) will nest @types/chai under node_modules/cypress/node_modules - meaning you’ll have 2 versions of chai type definitions. Since it is a namespace (global), TypeScript will throw a duplicate identifier.

One of the solutions that worked well for me in this case (duplicate definitions) was to have a tsconfig.json inside the cypress folder that looked like this:

{
  "extends": "../tsconfig",
  "compilerOptions": {
    "baseUrl": "../node_modules",
    "target": "es5",
    "types": ["cypress"],
  },
  "include": [
    "**/*.ts"
  ]
}

The extends is useful if you have a base tsconfig.json. Without it, you’ll have to determine your own compiler options for the cypress directory.

A nuclear option would be to add skipLibCheck set to true which will disable TypeScript type checking inside lib files.

This worked for me! Thank you!

I had the same error. Adding the following to my tsconfig.json solved the problem for me.

    "types": [
      "./support/index"
    ]

Finally got it to work with tsconfig.json like in https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/preprocessors__typescript-webpack:

  "include": [
    "node_modules/cypress/types/index.d.ts",
    "node_modules/cypress/types/blob-util.d.ts",
    "node_modules/cypress/types/minimatch.d.ts",
    "node_modules/cypress/types/bluebird.d.ts",
    "cypress/**/*.ts"
  ]

However, if i do something like

  "include": [
    "node_modules/cypress/types/\*",
    "cypress/**/*.ts"
  ]

"node_modules/cypress/types/chai.d.ts" is also included and those definitions clash with the chai typings that are installed in node_modules/@types/ due to cypress dependencies in its package.json:

@types/chai/index.d.ts (39,17) Duplicate identifier ‘Operator’… bug?

Adding /// <reference types="cypress" /> in top of every file solves the issue, playing around with tsconfig does not. For me maybe an extension messes up something.

This was my issue- prettier is formatting that to // / <reference types="cypress" /> 😭

Just a quick note for Atom: the second cypress/tsconfig.json with "types": ["cypress"] and "extends": "../tsconfig", was only recognized after restart.

We have this other issue that explains this… https://github.com/cypress-io/cypress/issues/1236

Both, VS code doesn’t see the typings neither the compiler.

One has to follow the below step after making the necessary config changes:

You may have to restart your IDE’s TypeScript server if the setup above does not appear to work. For example:

VS Code (within a .ts or .js file):

• Open the command palette (Mac: cmd+shift+p, Windows: ctrl+shift+p)

• Type “restart ts” and select the “TypeScript: Restart TS server.” option

If that does not work, try restarting the IDE.

Link to docs for typescript support

After trying all the solutions above, I just had to mix the two most useful comments for me by @NicholasBoll :

https://github.com/cypress-io/cypress/issues/1152#issuecomment-374930065 https://github.com/cypress-io/cypress/issues/1152#issuecomment-435560901

…and it works as it should. : ) 👍

I finally figured out that, for some reason, awesome-typescript-loader is incompatible with the cypress-webpack-preprocessor-plugin, and throws these errors. Switching to ts-loader fixed things for me.

It shouldn’t be necessary if you’ve set up everything the way the TypeScript Doc laid out.

For some miraculous reason it has resolved itself and as I am not really in the mood if debugging something as big as Cypress, so I was very careful not to even shut down my machine, in case it stops working again. May I ask though, on this note, if you believe that the comment /// <reference types="cypress" /> is necessary for this feature to fully work? I included it, but it’s kind of an eyesore, something that is only there because someone on the interwebs claimed this might help 😃

Happens with local install too. Interesting how such a minor thing can go on for many many months without getting resolved.

@Knaledge I confirmed that this is happening when Cypress is installed globally, see https://github.com/cypress-io/cypress/issues/2438