Overriding tsconfig.json path

[CSchulz]

What would you like?

At the moment the ts-node configuration searches the tsconfig.json at the cypress config file location.
This should be overridable.

Why is this needed?

We are using different tsconfig.json files for local development and running on ci machines.
It would be nice to have the possibility to override the tsconfig.json path during the startup of cypress.

Other

No response

[AtofStryker]

Hey @CSchulz . We usually recommend putting the tsconfig inside the cypress directory, though you might need to include type definitions in the root. Does this work for your use case?

[CSchulz]

It works for me, but it doesn't satisfy my need for a second tsconfig.json file.
At local development we are building everything from scratch even the shared cypress parts. On the CI we are trying to reuse every built artifact so we are loading the shared cypress parts from the registry.
For this case we are using different path mappings in the tsconfig.json files.

[AtofStryker]

I believe that makes sense. I am going to mark this as a feature request then. It might be good to have a small repository that shows the use case / need if possible.

[vkhytskyi-allegro]

Hello guys! At Allegro we faced a similar issue and would like to be able to customize tsconfig.json path.

It might be good to have a small repository that shows the use case / need if possible.

I created a repository to illustrate the problem. @AtofStryker please take a look.

[AtofStryker]

@vkhytskyi-allegro the link 404s for me. Is the link still valid?

[vkhytskyi-allegro]

@vkhytskyi-allegro the link 404s for me. Is the link still valid?

Accidentally made the repo private. It should be publicly accessible now.

[AtofStryker]

@vkhytskyi-allegro I believe I was able to reproduce. With conflicting tsconfig.json in the root I got the following error:

removing the tsconfig.json from the root "resolves" the issue

[vkhytskyi-allegro]

@AtofStryker Yes, but the tsconfig.json file from the root folder is used to build the web application. I could rename the file or use some environment variables, like TS_NODE_PROJECT or TS_NODE_COMPILER_OPTIONS, but, from my perspective, it is a bit inconvenient that the testing tool imposes how the file, that seems to not be relevant, should be named or configured. I would love to see Cypress provide an official way to customize path to tsconfig.json that is to be used by ts-node. At bare minimum, I think, this case should be mentioned in TypeScript documentation page to avoid possible confusion.

[lmiller1990]

Any proposal for how this API should look? It cannot be in cypress.config.js, we need to execute that using ts-node, which means we need to know where to look for the tsconfig.json ahead of time.

Using a script (bash, or Node.js with the Cypress Module API) and dynamically changing TS_NODE_PROJECT seems the most flexible way to do this. I don't think a CLI argument like --tsconfig makes sense - Cypress should not be coupled to TypeScript in this fashion.

I understanding writing a script with some process.env.CI logic isn't as simple or clean, but it is vastly more flexible. I've done similar custom setups in the past, and this approach worked well. Would it help if I could share some ideas on how I'd do this? It could be as simple as:

// scripts/runCypress.js

const cypress = require('cypress')
const fs = require('fs')

if (process.env.CI) {
  fs.copyFile('tsconfig.ci.json', 'cypress/tsconfig.json')
} else {
  // use default for local development
}

Then you could just add something in your package.json

{
  "scripts": {
     "cypress:run": "node scripts/runCypress.js"
  }
}

Would this solve the problem? We can still consider the feature request, but for those looking for something now, this could be a good solution.

[davidhousedev]

We're encountering issues with this after migrating to use references and composite for our root tsconfig.json. It seems that Cypress is using the project root tsconfig.json file to coordinate quite a bit, and there doesn't appear to be a way of overriding this. Ideally, we'd be able to have a tsconfig.cypress.json at the project root that is referenced by tsconfig.json via references.

The move to references and composite is fairly important to us working in a monorepo where typechecks can take a long time without splitting up directories into composite TypeScript projects.

[iongion]

For some reasons my cypress 13.8.1 does completely ignore ./cypress/tsconfig.json when ./tsconfig.json is present in the project root dir. I have no clue how to solve it. I can't use the root one as it is for the app itself and the IDE. Did any of you encounter this situation ?

[Onurfesci]

Having a similar issue... the my app/cypress/tsconfig.json:

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "baseUrl": ".."
  }
}

This extends the one in the app, which extends a shared tsconfig:

{
  "extends": "tsconfig/nextjs.tsconfig.json",
  "compilerOptions": {
    "baseUrl": ".",
    "types": ["cypress", "node", "@percy/cypress", "@serwist/next/typings"],
    "lib": ["dom", "dom.iterable", "esnext", "WebWorker"]
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  "exclude": ["node_modules"]
}

Which has paths defined. If I add the paths to the one above, which the cypress tsconfig extends, it works fine, but when it's a nested extends, paths doesn't seem to register and the cypress build throws an error saying imports aren't found..

Note: I also have a pnpm workspace with "tsconfig": "workspace:*" dependency in the root package.json. If I move "tsconfig": "workspace:*" to the app's package.json, it also works fine..

[tiosalazar]

Do you have any solution here? I'm facing the same problem

[blainemuri]

I'm also wondering if there's a solution yet

[jonathan-glitcher]

Running into same/similar issue.

@iongion im wondering with what you said would that mean if we did some hacky deletion like rm tsconfig.json during a ci process, or something to omit it, that cypress will resort to using the ./cypress/tsconfig.json?

[AtofStryker]

We are going to be adding this to the Cypress 15 release scope. If it doesn't make it in the first major release, it will be delivered as a feature post the 15.0.0 main release. We are able to support this fairly easily after #31520 since tsx allows us to use a TSX_TSCONFIG_PATH to process a file