Linking for reference: babel/babel#16192 - thanks for posting!

Giving this the ❤️ reaction as I'm enthused you're trying it out... and the 😕 reaction because I'm sad it's slower on your end. Darn.

Though, I tried a direct clone -> npx eslint . on that project, and saw it get slightly faster when I switched to either "project": true or "EXPERIMENTAL_useProjectService": true. Was that 31 -> 34 seconds measurement done as an average / through hyperfine or an equivalent?

Measurements from hyperfine "npx eslint ." -i on Node v20.2.0 on my M1 Max:

Note that EXPERIMENTAL_useProjectService had no lint complaints whereas the other two had identical ones. I didn't bother building fully to get a true comparison from 0 lint failures. Is there a quick set of build commands I can run?

Oh, and I filed #8189 to track adding docs for logging info. That issue has some more info in it on the DEBUG flags you can provide.

Thanks Josh! I've tried again with this hyperfine invocation:

hyperfine "./node_modules/.bin/eslint --ignore-path .gitignore --max-warnings 0 --ext ts,js,cjs ./dev-esbuild ./dev-node-loader ./dev-node-suppress ./dev-pnpm-test ./lib-collection ./lib-concurrency ./lib-error ./lib-hex-ts ./lib-payload ./lib-random ./lib-stream ./lib-style ./lib-test ./lib-time ./lib-widget ./svc-auth-guest-read ./svc-auth-guest-view ./svc-gateway-guest-run"

Setup:

• git checkout ec6d173f390e02762145a762b97acebe5eaa0b9e
• pnpm i
• ./node_modules/.bin/tsc --build

This is a more positive result. Switched my repo over to EXPERIMENTAL_useProjectService now ✔️

What I previously saw as "34 seconds" was definitely user CPU time (nice that hyperfine reports this too), not total time, sorry for the confusion!

I got lots of logs with --debug, but didn't see any obvious differences with parserOptions.debugLevel or any obvious TypeScript problems. Is there anything I could look for that would relate to the new project service?

Is there anything I could look for that would relate to the new project service?

🙌 Love that you're asking this! At this point your best bet is probably to search for useProgramFromProjectService in the typescript-eslint source and see where that gets called. Logs generally come from a const log = debug(. If there are points you'd want logged but is not yet, Local Development -> Local Linting can get you to a place where you can add those locally and try them out. If you find anything particularly useful please do file an issue suggesting we add them. We don't have complete coverage of those and so can always look into adding more.

Ah that's misconfigured: it's not projectService yet. For now it's EXPERIMENTAL_useProjectService. #6403 tracks adding a notice for typos like that.

Ok. Can you edit the OP to clarify the +- instructions? That's what I was going off of.

I tried this out via this commit, but I got this new error: https://github.com/IsaacScript/isaacscript/actions/runs/7431948579/job/20223198672

Aha! Thanks for mentioning. This is #8206: the project service doesn't (yet?) provide a tsconfig.json's compiler options for a neighboring file not included in that tsconfig.json.

I'm surprised I hadn't yet filed an issue for this. It's been on the back of my mind for a while... adding the issue to the v7 milestone too.

I also think the default value of 8 is too small.

@black7375 why? Could you provide more information? Saying you disagree without giving reasoning is not very useful for us in considering a new default.

In our opinion of you're using the default program for more than 8 files you're doing it wrong and will be causing a performance impact for your lint run.

The option is there to cover a few config files - not for anything more. Which is why we banned wide globs from the option.

I use a split screen on a wide monitor (two by default)
However, when writing code, frequently used utilities and types are separated into different files, and UI components are also separated.
Therefore, it was very easy to exceed the limit of eight as I worked.

I'm not quite sure what you're talking about here. The option and the value 8 has no relationship to the number of files you can open in your editor.

It's the number of files we allow you to cover with the default program - I.e. Files not covered by a tsconfig.json.

I was completely misunderstanding it - it didn't appear when I opened a small number of files, but when I opened a large number of files, the error appeared in the editor and I thought it meant the number of files opened.
Thank you for your kind response.

I haven't run the code - but my basic understanding would have been that TS will pick the tsconfig.json by default which is configured to include all files - so it'll pick up app.ts, test.ts, other.d.ts and test.d.ts under the one config file.
It'll probably error on one of the .d.ts files (probably test.d.ts cos it's alphabetically second) if you turn off skipLibCheck.

Yup, @bradzacher is right - tseslint is going with the proper behavior here.

The root tsconfig.json includes all files. It doesn't have an include and doesn't use project references - so any consumer of the project service will use it for all files when there isn't any nested tsconfig.json to override it. That includes both tseslint's project service and editors such as VS Code. If you want to have VS Code and the typescript-eslint project service use tsconfig.*.json files instead, you'll want to use TypeScript project references.

Does that all make sense and sound reasonable to you @cexbrayat?

I wonder if we'll want to add this to the troubleshooting docs as part of #9085...

Thank you for taking the time to look into it @bradzacher and @JoshuaKGoldberg
Yes, it makes sense, I'll bring that up to the Angular CLI team, because it should probably be fixed there.
Thanks again

Ah good note, these aren't explicitly called out in https://typescript-eslint.io/packages/parser#projectserviceoptions. But they're both undefined/falsy by default.

Note also #9807 for suggesting setting defaultProject's default to 'tsconfig.json'.

Hmm, I don't know what information we could provide here that would be useful to you. parserOptions.projectService is a parser option (within language options) as defined by the ESLint API: https://eslint.org/docs/latest/use/configure/language-options.

We don't maintain eslint-import-resolver-typescript in typescript-eslint and aren't familiar with how it works. My advice would be to talk with the maintainers there. If you have any specific questions for us, we could take a look.

Yeah there's nothing special about the project service - that's our side of the fence. On the 3rd party side the thinking is just in terms of non-type-aware / pure syntactic rules vs type-aware rules.

Right now eslint-plugin-import and friends consume no type info currently. But they could do if they wanted. They could check the parser services on the context and consume the type info instead of manually building state from disk manually.

These are probably the mode relevajt docs:
https://typescript-eslint.io/developers/custom-rules#typed-rules

Thank you for the answer. I have to say this area goes a bit over my head, I was mostly wondering if https://github.com/import-js/eslint-plugin-import & https://github.com/un-ts/eslint-plugin-import-x could use a similar approach as typescript-eslint to find the tsconfigs instead of having to do:

{
  "settings": {
    "import-x/resolver": { // Updated to import-x
      "typescript": {
        "alwaysTryTypes": true,
        "project": [ // Could this be `"project": true` or use the project service ?
          "tsconfig?(.*).json",
          // From our Angular preset
          "projects/*/tsconfig?(.*).json",
          "*/tsconfig?(.*).json" // For example: e2e/tsconfig.json
        ]
      }
    }
  }
}

But I don't myself know or understand exactly what for and how they use that config. I've transferred this answer to the developper.

I also just found back the following discussion which is relevant: un-ts/eslint-plugin-import-x#40 (comment)