Fix 'ESLint was configured to run on' in Cypress tests

TL;DR#

typescript-eslint can only produce type information for a file that one of the TSConfigs listed in parserOptions.project actually contains. The Stack Overflow question shows two ways to end up with none: the root tsconfig.json has "exclude": ["./cypress", ...], which drops every .cy.ts file even though include lists ./cypress/**/*.cy.ts, and its .eslintrc.js sets a relative project without tsconfigRootDir, so the path depends on where ESLint runs. Keep the layout Cypress recommends (root excludes cypress, cypress/tsconfig.json includes its own files) and tell ESLint about the second TSConfig: project: ['./tsconfig.json', './cypress/tsconfig.json'], or switch to projectService: true. Removing project, the most upvoted answer, only works while no type-aware rule is on.

The three wordings of the same error#

The question shows the wording older typescript-eslint releases printed:

Parsing error: ESLint was configured to run on `<tsconfigRootDir>/component/TestComponent.cy.ts` using `parserOptions.project`: <tsconfigRootDir>/../../../../../../users/tduke/desktop/dev/blog/cypress/tsconfig.json
However, that TSConfig does not include this file. Either:
- Change ESLint's list of included files to not include this file
- Change that TSConfig to include this file
- Create a new TSConfig that includes this file and include it in your parserOptions.project

The failure was reproduced on 19 October 2026 in the official node:22-alpine Docker image with Node 22.23.3, ESLint 9.39.5 (flat config), typescript-eslint 8.71.2 and TypeScript 6.0.3, using the question's tsconfig.json (compiler options trimmed, and remix.env.d.ts dropped from include), one source file in app/ and the question's test file at cypress/component/TestComponent.cy.ts. Run from the terminal with npx eslint, the current release prints a shorter message:

/app/cypress/component/TestComponent.cy.ts
  0:0  error  Parsing error: "parserOptions.project" has been provided for @typescript-eslint/parser.
The file was not found in any of the provided project(s): cypress/component/TestComponent.cy.ts

With the same files and long-running mode forced through the TSESTREE_SINGLE_RUN=false environment variable, the current wording of the question's message comes back:

/app/cypress/component/TestComponent.cy.ts
  0:0  error  Parsing error: ESLint was configured to lint `<tsconfigRootDir>/cypress/component/TestComponent.cy.ts` with type information from `parserOptions.project`: <tsconfigRootDir>/tsconfig.json
However, that TSConfig does not include this file, so type information is not available for it. Either:
- Change ESLint's list of included files to not include this file
- Change that TSConfig to include this file
- Create a new TSConfig that includes this file and include it in your parserOptions.project
See the typescript-eslint docs for more info: https://tseslint.com/none-of-those-tsconfigs-include-this-file

The two code paths live in different files of @typescript-eslint/typescript-estree: the short message is built in useProvidedPrograms, the long one in createProjectProgramError.ts. Which one runs is decided by inferSingleRun.ts, whose comment separates "an ESLint CLI invocation" from "long-running sessions (such as continuous feedback on a file in an IDE)". It treats CI=true and a binary under node_modules/.bin/eslint as a single run, except when the command line contains --fix. So a plain npx eslint and an npx eslint --fix on the same file can show you different text for one cause.

Why the Cypress test file has no program#

Two TypeScript rules combine here. The include reference says patterns resolve relative to the directory that holds the tsconfig.json. The exclude reference says it "Specifies an array of filenames or patterns that should be skipped when resolving include". exclude wins over include: listing ./cypress/**/*.cy.ts in include while ./cypress sits in exclude adds nothing. A negative control confirms that the path spelling is not the problem: changing project: './tsconfig.json' to project: 'tsconfig.json', the guess in the second answer, printed the identical error.

The exclusion is not a mistake in itself. The Cypress TypeScript guide recommends a separate cypress/tsconfig.json with "include": ["**/*.ts"], and, when Jest also runs in the repo, excluding cypress and cypress.config.ts from the root config "so that Jest does not pick up Cypress global types". The asker's root config loads vitest/globals, a second set of global test functions in the same project. The question's file is set up the Cypress way. The missing piece is on the ESLint side: parserOptions.project points at the root config only, and per the parser docs, "If this setting is specified, you must only lint files that are included in the projects as defined by the provided TSConfig file(s)."

The path in the original message points at the second route. The file is shown relative to tsconfigRootDir (<tsconfigRootDir>/component/...), so the root dir was the cypress folder, and the TSConfig it names is cypress/tsconfig.json, not the root file pasted in the question. The question's .eslintrc.js sets project: './tsconfig.json' and no tsconfigRootDir, and the parser docs state: "Relative paths are interpreted relative to the current working directory if tsconfigRootDir is not set." Run from the cypress folder, that relative path names cypress/tsconfig.json. The same page now gives "the directory of the ESLint config file" as the tsconfigRootDir default, so the two statements leave room for doubt on any given version; setting tsconfigRootDir yourself removes it. This route is documented, not reproduced here. It is why the second and third answers both add tsconfigRootDir: __dirname, and why every config below sets tsconfigRootDir: import.meta.dirname. Read the TSConfig path in your own message first: it is the config that failed to contain the file. The long <tsconfigRootDir>/../../../.. prefix was a display bug, typescript-eslint issue #6289, closed in February 2023. The current describeFilePath prints such paths in full.

Fix: give ESLint a TSConfig that contains the file#

Option 1: list the Cypress TSConfig in parserOptions.project#

1. Create cypress/tsconfig.json as the Cypress guide shows. The repro dropped the guide's "types": ["cypress", "node"] line because Cypress itself was not installed in the container. Keep it in a real project.

{
  "compilerOptions": { "target": "es6", "lib": ["es6", "dom"], "sourceMap": true },
  "include": ["**/*.ts"]
}

2. Point parserOptions.project at both configs. This was the only change between the failing and the passing run:

import tseslint from "typescript-eslint";
 
export default tseslint.config(
  {
    files: ["**/*.ts"],
    extends: [tseslint.configs.base],
    languageOptions: {
      parserOptions: {
        project: ["./tsconfig.json", "./cypress/tsconfig.json"],
        tsconfigRootDir: import.meta.dirname,
      },
    },
    rules: { "@typescript-eslint/no-floating-promises": "error" },
  },
);

With only the root config listed, the same files still failed with "The file was not found in any of the provided project(s)". With both listed, npx eslint cypress/component/TestComponent.cy.ts exited with code 0. The parser takes the first listed TSConfig that includes the file, as the typed-linting troubleshooting page describes.

On a legacy .eslintrc.js, as in the question, the parser docs give the CommonJS form tsconfigRootDir: __dirname. The same project array goes next to it. That variant was not run here.

Option 2: let the project service find the nearest tsconfig.json#

The parser docs now recommend projectService over project. It looks up the nearest tsconfig.json for each linted file, as project: true does. With the root config still excluding ./cypress and no cypress/tsconfig.json, it fails with its own message:

/app/cypress/component/TestComponent.cy.ts
  0:0  error  Parsing error: /app/cypress/component/TestComponent.cy.ts was not found by the project service. Consider either including it in the tsconfig.json or including it in allowDefaultProject

Adding a cypress/tsconfig.json made the run pass, with no other edit. The repro used one that extends the root config and resets exclude; the Cypress guide's file from Option 1 is also named tsconfig.json, so the service finds it the same way:

{
  "extends": "../tsconfig.json",
  "include": ["**/*.ts"],
  "exclude": []
}

The ESLint config for this option:

import tseslint from "typescript-eslint";
 
export default tseslint.config(
  {
    files: ["**/*.ts"],
    extends: [tseslint.configs.base],
    languageOptions: {
      parserOptions: { projectService: true, tsconfigRootDir: import.meta.dirname },
    },
    rules: { "@typescript-eslint/no-floating-promises": "error" },
  },
);

The project service only reads files named tsconfig.json or jsconfig.json, so a cypress/tsconfig.eslint.json would not be picked up. Do not set project and projectService together either: the parser rejects that combination with "Enabling "project" does nothing when "projectService" is enabled".

Option 3: lint Cypress specs without type information#

If the specs do not need type-aware rules, keep project for the app and switch type checking off for the test files with the disableTypeChecked shared config. This run passed against the root config that still excludes ./cypress:

import tseslint from "typescript-eslint";
 
export default tseslint.config(
  {
    files: ["**/*.ts"],
    extends: [tseslint.configs.base],
    languageOptions: {
      parserOptions: { project: "./tsconfig.json", tsconfigRootDir: import.meta.dirname },
    },
    rules: { "@typescript-eslint/no-floating-promises": "error" },
  },
  { files: ["cypress/**/*.cy.ts"], extends: [tseslint.configs.disableTypeChecked] },
);

Verify the fix#

Run the same file through both code paths, because an editor and the terminal do not take the same one:

npx eslint cypress/component/TestComponent.cy.ts
TSESTREE_SINGLE_RUN=false npx eslint cypress/component/TestComponent.cy.ts

With the Option 1 config and the root config still excluding ./cypress, both commands exited with code 0 in the repro. If the terminal passes and the editor still complains, compare the TSConfig path printed in the editor's message with the one you edited: the message always names the config it tried.

Why removing project only hides the problem#

The top answer comments out project and keeps tsconfigRootDir. That stops the parser from looking for a program, so the parsing error disappears. But any type-aware rule now has nothing to run on. With @typescript-eslint/no-floating-promises enabled, the same command crashed instead:

Error: Error while loading rule '@typescript-eslint/no-floating-promises': You have used a rule which requires type information, but don't have parserOptions set to generate type information for this file. See https://tseslint.com/typed-linting for enabling linting with type information.

If that is the next message you see, you have swapped one error for another. Go back to Option 1 or 2. Option 3 is the honest form of "no type information for these files". A different typescript-eslint parsing error, the originalKeywordKind DeprecationError, comes from @typescript-eslint v5 packages running against TypeScript 5. That one is fixed by upgrading the parser and plugin to v6 or later, not by touching project.

Putting Cypress back into the root tsconfig, and what exclude costs you#

The other route is to stop excluding cypress from the root config. In the repro, a root config with ./cypress removed from exclude passed. That run changed more than one thing: it also put node_modules back into exclude and trimmed the include list. So treat it as a variant, not as a single-change proof. It also brings back the clash between Cypress and Jest or Vitest globals that the Cypress guide wants to avoid.

Whatever you choose, remember that writing exclude replaces its default. According to the TSConfig reference data, the default is node_modules, bower_components, jspm_packages and the outDir. The question's root config sets exclude without node_modules, as the third answer points out. A TypeScript 6 detail matters too when you split configs: types now defaults to an empty list. Globals then only exist where a config lists them explicitly, the same mechanism behind Cannot find name 'console' (TS2584). Finally, typescript-eslint 8.71.2 declares a peer range of typescript >=4.8.4 <6.1.0 on the npm registry, while the registry's latest TypeScript is 7.0.2. Pin TypeScript inside that range when you reinstall to test these changes; the repro used 6.0.3 for that reason.

Once the parser has a program for every file it lints, the remaining messages come from rules, not from configuration. Suppressing those is a separate topic: Unexpected any. Specify a different type shows which disable comments ESLint actually reads. For formatting rules that fight each other in the same config, see the Prettier and ESLint indent conflict. The rule to keep from this error is short: every file ESLint lints with type information must belong to a TSConfig you listed, and exclude decides that before include gets a say.

Further reading: Fix 'The keyword enum is reserved' in ESLint + TypeScript, Fix 'was not found by the project service' in ESLint.