Skip to content

Bug: flat configuration block options are not independent #6778

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
4 tasks done
JP-Ellis opened this issue Mar 27, 2023 · 1 comment
Closed
4 tasks done

Bug: flat configuration block options are not independent #6778

JP-Ellis opened this issue Mar 27, 2023 · 1 comment
Labels
bug Something isn't working working as intended Issues that are closed as they are working as intended

Comments

@JP-Ellis
Copy link

JP-Ellis commented Mar 27, 2023

Before You File a Bug Report Please Confirm You Have Done The Following...

  • I have tried restarting my IDE and the issue persists.
  • I have updated to the latest version of the packages.
  • I have searched for related issues and found none that matched my issue.
  • I have read the FAQ and my problem is not listed.

Issue Description

First and foremost, this bug relates to the new ESLint flat configuration. I understand that this feature is still in beta and is now in Phase 3 which is to ensure compability with existing plugins. I suspect the error is with the TypeScript parser and not with ESLint.

Expected Behaviour

I should be able to configure options for the TypeScript parser independently when it is used within the TypeScript section of the config, and the Svelte section of the configuration.

Actual Behaviour

The setting of languageOptions in the block of the ESLint config targetting **/*.ts files has side-effects, impacting the use of the TypeScript parser in the Svelte section targettin **/*.svelte files.

In the example repo (below), the ESLint config contains the following segment:

https://github.com/JP-Ellis/eslint-plugin-svelte-mwe/blob/f09107de3dcb59704a4e6d416b26eaa720f25c10/eslint.config.js#L20-L36

I note the following behaviours:

  • When it is commented out, the *.svelte files are parsed and linted correctly. The TypeScript files are not linted, which is expected as non of the configuration blocks in ESLint match *.ts files
  • When the TypeScript configuration block is uncommented, the *.ts files are correctly linted; however, the *.svelte files produce the following error relating to tsconfig.ts:
      0:0  error  Parsing error: ESLint was configured to run on 
    `<tsconfigRootDir>/src/routes/+page.svelte` using `parserOptions.project`: 
    <tsconfigRootDir>/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
    See the typescript-eslint docs for more info: https://typescript-eslint.io/linting/troubleshooting#i-get-errors-telling-me-eslint-was-configured-to-run--however-that-tsconfig-does-not--none-of-those-tsconfigs-include-this-file
    
  • Adding extraFileExtensions: [".svelte"] to the languageOptions in the TypeScript block (and having it uncommented) resolves the above issue.

My expectation is that the settings passed in the TypeScript config block should be independent of the settings passed in the Svelte block.

Reproduction Repository Link

https://github.com/JP-Ellis/eslint-plugin-svelte-mwe

Repro Steps

  1. clone the repo
  2. pnpm install
  3. pnpm lint (this should work fine)
  4. Uncomment the TypeScript configuration in eslint.config.js
  5. pnpm lint (this should produce errors)
  6. Add extraFileExtensions: [".svelte"] to the languageOptions in the TypeScript block.
  7. pnpm lint (this should have fixed the previous issue)

Versions

package version
@typescript-eslint/eslint-plugin 5.56.0
@typescript-eslint/parser 5.56.0
TypeScript 5.0.2
ESLint 8.36.0
node 19.8.1
@JP-Ellis JP-Ellis added bug Something isn't working triage Waiting for team members to take a look labels Mar 27, 2023
@JP-Ellis JP-Ellis changed the title Bug: Flat Bug: flat configuration block options are not independent Mar 27, 2023
@bradzacher
Copy link
Member

bradzacher commented Mar 27, 2023

We cache the program created for each tsconfig as a singleton for the duration of the lint.

It just so happens that the first file that ESLint asks us to parse is a .ts file (because it's closer to the project root than the svelte file).
So we create a program for ./tsconfig.json with extraFileExtensions: [].
Next ESLint asks svelte-eslint-parser to parse the svelte file. When it parses the script block, I assume it's like the vue parser - i.e. it calls into our parser again with the block contents, passing the options provided.
Based on your config that means that it asks our parser to do a type-aware lint for ./tsconfig.json with extraFileExtensions: [".svelte"].

However - we've already got a cached program from before so we just return that - i.e. we ignore the extra config you've passed in.

The solution is to ensure the parser options are consistent for a given project path (which you have already found to work).


For us to support this style of inconsistent config we would need to keep two copies of the program around - one for each set of parser options you pass in. This is a non-starter because it would waste a lot of time (program creation is expensive) and waste a lot of memory (again, expensive).

Parsers like the svelte or vue parser are special cases that (TBH) hack around the ecosystem to add support for TS. Standard TS usage does not create scenarios in which you will have multiple sets of parser options for the same tsconfig files like this.


It's worth noting that I don't believe this has anything to do with flat config - you would hit the exact same problem with a classic config because it's an ordering problem.

@bradzacher bradzacher added working as intended Issues that are closed as they are working as intended and removed triage Waiting for team members to take a look labels Mar 27, 2023
@bradzacher bradzacher closed this as not planned Won't fix, can't repro, duplicate, stale Mar 27, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working working as intended Issues that are closed as they are working as intended
Projects
None yet
Development

No branches or pull requests

2 participants