Before You File a Documentation Request Please Confirm You Have Done The Following...

• I have looked for existing open or closed documentation requests that match my proposal.
• I have read the FAQ and my problem is not listed.

Suggested Changes

Established community documentation is apparently out of date since the introduction of the object-style of projectService field so I've been guessing what the content of eslint.config.mjs should be from various examples and conversations I've found.

It's unclear to me where anyone can find the POLA configuration, directing typescript-eslint rules to apply to your project's typescript files (as defined by tsconfig.json).

After attempting to integrate the typescript-eslint package to employ type-aware linting for my project, I find that all manner of other files are suddenly being considered as needing type information and compiler declarations, even though they don't match the "include" pattern of my typescript project. This leads to new apparently unfixable linting issues.

The landing documents don't clearly direct how anyone would configure typescript-eslint at all in this scenario. Following the default instructions immediately fails with messages like this...

error  Parsing error: /Users/me/workspace/myproject/modules/typescript-utils/coverage/block-navigation.js was not found by the project service. Consider either including it in the tsconfig.json or including it in allowDefaultProject

The only two alternatives provided are either

• Treat the failing file as typescript by adding it to tsconfig.json includes
• Treat the failing file as typescript by declaring it as a pattern that is an honorary member associated with some tsconfig.json

I've no idea why these files are being treated as typescript at all to begin with, and I've struggled to find a sensible way to bring typescript-eslint under control in this regard. Can we have a record of the starting config that uses type-aware linting for the typescript files detailed in the include of your tsconfig.json ?

Affected URL(s)

https://typescript-eslint.io/getting-started

Additional Info

The guess I've made for our desired linting configuration is as follows, but suffers from the problems detailed below.

export default [
  ...tseslint.config(
    ...rokuConfigExceptTseslint,
    ...tseslint.configs.strictTypeChecked,
    ...tseslint.configs.stylisticTypeChecked,
    {
      ignores: ["dist/", ".rollup.cache/", "eslint.config.mjs"],
    },
    {
      rules: {
        "@typescript-eslint/no-floating-promises": "error",
      },
    },
    {
      languageOptions: {
        parserOptions: {
          projectService: true,
          tsconfigRootDir: import.meta.dirname,
        },
      },
    },
  ),
]

My typescript project, defined using the Typescript convention of tsconfig.json, like this...

{
  "extends": "../../tsconfig.base.json",
  "include": ["src/**/*"],
  "compilerOptions": {
    "rootDir": "../",
    "declaration": true,
    "declarationMap": true
  }
}

Concrete examples of files incorrectly picked up by typescript-eslint are vite.config.ts which are deliberately outside src and have never successfully compiled which is one reason we have a narrower set in our include. Others that typescript-eslint seems to think it can have a go at are test/env.test.ts, typedoc.mjs, coverage/block-navigation.js.

I'm sure it's wrong for me to attempt one-by-one setting patterns to match every non-project file and configure it to be a virtual member of some typescript project. Equally I don't expect to add special rules to tell it every file in our software build system that isn't typescript and isn't built as part of your project. That seems redundant. Given it's a typescript tool, it also doesn't make sense to redeclare a list of files to include in type-aware linting. The tsconfig.json already has an include field detailing the typescript files in the project.

It would be great to see an example documented that takes account of the apparent requirement for projectService declaration that comes from typescript-eslint's apparent out-of-the-box promiscuous behaviour with non-project typescript files and non-typescript files. Is this behaviour new since adding projectService?