Interesting. #5762 should improve the error message a bit. Two things fix this locally for me:

• Removing the references from tsconfig.json
  • We don't yet support project references: Support for Project References #2094
• Enabling parserOptions.EXPERIMENTAL_useSourceOfProjectReferenceRedirect per feat(typescript-estree): add flag EXPERIMENTAL_useSourceOfProjectReferenceRedirect #2669

My recommendation here would be to do either of those two things, or if you can't, set up a tsconfig.eslint.json as described in https://typescript-eslint.io/docs/linting/typed-linting/monorepos.

As to why those specific files do or don't get the parsing error... great question. Marking as this needing an investigation.

Something weird is happening with the project references yeah.
How come you have both a tsconfig.json AND a tsconfig.app.json **that are exactly the same?

Similarly your tsconfig.vitest.json has no includes - which means it includes every single file in your project.

For some reason the combination of the duplicated tsconfig and the unrestricted includes in project references causes TS to exclude src/router.js from the program.

What makes it weirder is that TS gives us inconsistent information:

• program.getRootFileNames() returns

  Set(3) {
    'env.d.ts',
    'src/main.js',
    'src/router.js'
  }
  

• program.getSourceFiles() returns

  Set(34) {
    // ... snip node modules ...
    'env.d.ts',
    'src/main.js'
  }
  

So TS knows that src/router.js is a root file, but it doesn't create a source file for it.
I don't know why exactly. I was under the impression that TS should completely ignore the project references for our call. Probably worth following up with the TS folks? We'd need to create a repro without our library code - i.e. write small script which calls the TS APIs to reproduce this weird behaviour.

Regardless - cleaning up your project references so there's less duplication in the includes would be best.

I would suggest creating a single tsconfig for your entire project.

I'm going to close this for now because there are workarounds provided.
We'll investigate following up with TS separately.

The trouble is, the default vue project created with npm init vue@3 wants to do this whole "multiple .tsconfig" thing, where different .tsconfig files have different values for "extends". I'm not sure exactly what that's doing so I'm not sure how to translate it all into one .tsconfig.

@jez9999 check the guide I linked. It should help you setup a tsconfig.eslint.json to lint with.

@bradzacher Vue 3's default setup has a tsconfig.json that references 3 other files, which themselves variously extend @vue/tsconfig/tsconfig.web.json and @vue/tsconfig/tsconfig.node.json. These different configs have different includes so they apply different settings to different sets of files. How can this be recreated with a single tsconfig.json or even a tsconfig.eslint.json?

Interesting. #5762 should improve the error message a bit. Two things fix this locally for me:

• Removing the references from tsconfig.json

  • We don't yet support project references: Support for Project References #2094

• Enabling parserOptions.EXPERIMENTAL_useSourceOfProjectReferenceRedirect per feat(typescript-estree): add flag EXPERIMENTAL_useSourceOfProjectReferenceRedirect #2669

My recommendation here would be to do either of those two things, or if you can't, set up a tsconfig.eslint.json as described in https://typescript-eslint.io/docs/linting/typed-linting/monorepos.

As to why those specific files do or don't get the parsing error... great question. Marking as this needing an investigation.

If you ask me, @JoshuaKGoldberg, supporting project references should be a very high priority for this project. They seem to have been around now for 4 years and are presumably widely used. It's somewhat ridiculous they're not supported. Also, I tried adding that experimental flag in .eslintrc.cjs, and it didn't fix the errors here at all:

	"parserOptions": {
		"ecmaVersion": "latest",
		"project": "./tsconfig.json",
		"parser": "@typescript-eslint/parser",
		"EXPERIMENTAL_useSourceOfProjectReferenceRedirect": true
	},

It's somewhat ridiculous they're not supported

That sort of statement is a really harmful, inflammatory statement. It is based on a lack of understanding of the volunteer maintainers' circumstances as well as the very large scope of the problem.

I would thank you to not use such a tone, especially when you're asking people to volunteer their free time to help you out.

If you ask me supporting project references should be a very high priority for this project

Project references aren't something you can simply support because we don't support them - TS APIs support them.
We need involvement from the TS team to properly support them, but we as volunteer maintainers haven't have the bandwidth to get involved in such a collaboration because it will take a lot of time to properly spec it, build it and test it.

Right now the APIs TS provides to work with project references are not good for us - there are a number of cases for which they break the type-aware linting; which is why the flag is EXPERIMENTAL.