Extension gets stuck on parsing errors using generated tsconfig

[mcous]

Overview

I've been trying out using vscode-linter-xo in a TypeScript project, and I'm running into very frequent spurious "Parsing error: "parserOptions.project" has been set... The file does not match your project config".

This issue happens to me when xo is generating its own tsconfig due to a linted file not being present in the tsconfig specified by parserOptions.project.

The root cause of this issue may lie with xo itself, but I believe it's the result of a bad interaction between the extension and the linter itself, and probably a race condition somewhere.

Observations

I've been unable to get a consistent reproduction for this issue, but this is what I've observed. I'm thinking it might be a race between linting several files in the editor at the same time, or perhaps keeping the editor open while running xo from the command-line.

• After a lint run by the extension, the generated tsconfig will contain "files": ["/path/to/linted-file.ts"]
• After a subsequent extension run on another file, the "files" field will only contain the path to the new file
• After a lint run by the xo CLI, the "files" field of the generated tsconfig will instead contain all files in the project
• After the extension gets stuck, the "files" field will only contain one file, and parsing errors will be generated on all other files
  • Running the xo CLI or the extension will not cause a new tsconfig to be generated
  • The xo CLI will still succeed
• Once the extension is stuck, the only sure-fire resolution is to close all files, reload the editor and wipe out node_modules/.cache/xo-linter.

Workaround

I've worked around this issue by ensuring that xo never generates its own tsconfig by providing an xo-specific tsconfig that matches all necessary files.

[spence-s]

@mcous -- this really doesn't have much to do with this extension but it is a known problem for xo...historically tsconfigs have been the most difficult part of making xo work for everyone out of the box. - The current work around you are proposing is the best option and is generally what I've seen most ts xo users do, including myself, although I don't work on a lot of complicated ts projects.

I actually worked on the current handling of tsconfigs in xo, and would love to see improvements there. I just haven't had time since the workaround is generally fine for me when I need it. -- if you'd like any help with understanding what is happening in the xo code base in regards to TS I am happy to help there if you'd like to contribute.

[mcous]

@spence-s yeah, that makes total sense! I only ended up running into this issue because I also ran into xojs/xo#661, mentioned above - I provided a matching tsconfig to xo, but xo disagreed that it was a match, so tsconfigs started getting generated.

A few gut reactions upon reading the code for the first time:

• It struck me as odd that the hash in the generated tsconfig's filename would be the same even as the contents, via the "files" field, would change
• It also seemed strange that the generated tsconfig has its "includes" field always set to [], overwriting the "includes" field of the tsconfig it is extending
  • Instead of getting an extended tsconfig that also matches the file you're linting, you get an extended tsconfig that only matches the file(s) you're linting

I'll hit you up if I have any questions as I dig into these codebases some more and/or actually come up with a good reproduction or demonstration of this "stuck extension" issue

[spence-s]

@mcous awesome thanks for the help! I think if you can make sound improvements here PRs will be welcomed by @sindresorhus

One of the big differences between the cli and the vscode extension is the fact that the extention only lints a single file at a time ever. The cli almost is always linting multiple files and grouping them together to make the least amount of eslint runs possible. -- this difference is probably the source of the "choking" behavior you are describing if I had to guess.

When I wrote the tsconfig logic I was really focusing on optimizing xo performance and reducing the amount of times eslint was ran in a single run of xo and reducing the amount of file writing in the cache we were doing. -- There are just so many edge cases with these TSConfigs.

[spence-s]

I think this is fixed now, tsconfig resolution has recently improved in xo. Closing.