Skip to content

Enhancement: deprecate project setting in favor of projectService setting #11252

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.

Sign up for GitHub

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

Jump to bottom
Open
4 tasks done
benmccann opened this issue May 28, 2025 · 3 comments
Open
4 tasks done

Enhancement: deprecate project setting in favor of projectService setting #11252

benmccann opened this issue May 28, 2025 · 3 comments
Labels
enhancement New feature or request triage Waiting for team members to take a look

Comments

@benmccann
Copy link
Contributor

Before You File a Proposal Please Confirm You Have Done The Following...

Relevant Package

parser

My proposal is suitable for this project

  • I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

I had been using the project setting for quite awhile, unaware that there's a new projectService setting that's generally recommended in its place. I wonder if there could be some warning to help users discover this - either printed at runtime or via compile time type checking.

The docs say:

We now recommend using projectService instead of project for easier configuration and faster linting.

My own experience with projectService has been that it is indeed faster. I understand from #8031 that it's not the case for 100% of projects. However, when there is a difference, it looks to be on the order of a few percent. On the other hand, the project setting has much more ability for users to create pathological settings that can really harm their performance in a very meaningful way (e.g. #2611)

I also see in #8031 that it says:

Our priority for the next year will be to improve the new Project Service API so that it works in all places the traditional Program API does.
We won't remove the traditional project program behavior unless and until the new Project Service API is able to fully replace it.

I'm not sure if there's a list of differences that exists currently. It may be hard to discover the ways in which differences remain. Deprecating the project setting would encourage users to attempt a migration and report any difficulties.

Additional Info

If there is some decision to help more actively push users towards projectService it may be worth clarifying the updated stance in the pending blog post (#8031) and docs. I think in either case, the project setting would continue to be supported for awhile. It's really just a question of whether users should more actively be made aware of projectService as an alternative
@benmccann benmccann added enhancement New feature or request triage Waiting for team members to take a look labels May 28, 2025
@kirkwaiblinger
Copy link
Member

Hi @benmccann!

project sort of does two different things right now (docs).

  1. There's manual specification of tsconfigs, via project: string[] | string.
    • I think that this feature is necessary and not going to be considered for deprecation.
  2. There's a heuristic-based tsconfig lookup via project: true, which is generally superseded by projectService: true.
    • This is what can be considered for deprecation in The Future™️. The docs I checked already seem to pretty thoroughly point you to projectService: true wherever we mention project... so I think that's in a reasonable state for the present? Are the docs lacking in that regard? A runtime warning seems a little spammy to me until/unless project: true actually gets fully deprecated.

@benmccann
Copy link
Contributor Author

Is there a case where project: string[] | string is needed and the requirements can't be fulfilled by projectService? If so and there are no plans to expand projectService to cover those needs, should the note on the project docs be updated to clarify that it's only project: true that's discouraged?

@kirkwaiblinger
Copy link
Member

Is there a case where project: string[] | string is needed and the requirements can't be fulfilled by projectService?

See https://typescript-eslint.io/troubleshooting/typed-linting/#can-i-customize-the-tsconfig-used-for-the-project

If so and there are no plans to expand projectService to cover those needs, should the note on the project docs be updated to clarify that it's only project: true that's discouraged?

I think I would say that project: string[] | string is discouraged as well, but nonetheless required to support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request triage Waiting for team members to take a look
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@benmccann @kirkwaiblinger