cypress-io / cypress

Fast, easy and reliable testing for anything that runs in a browser.
https://cypress.io
MIT License
47.07k stars 3.19k forks source link

Overriding tsconfig.json path #23045

Open CSchulz opened 2 years ago

CSchulz commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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

vkhytskyi-allegro commented 1 year ago

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

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

AtofStryker commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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..