8000 Repo: Adopt `getConstraintInfo` internally · Issue #10569 · typescript-eslint/typescript-eslint · GitHub
[go: up one dir, main page]
Skip to content

Repo: Adopt getConstraintInfo internally #10569

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
kirkwaiblinger opened this issue Dec 30, 2024 · 2 comments
Open

Repo: Adopt getConstraintInfo internally #10569

kirkwaiblinger opened this issue Dec 30, 2024 · 2 comments
Labels
blocked by another issue Issues which are not ready because another issue needs to be resolved first repo maintenance things to do with maintenance of the repo, and not with code/docs

Comments

@kirkwaiblinger
Copy link
Member

Suggestion

This is a followup to #10438 and #10496.

Now that we have getConstraintInfo, we should use it internally and remove our existing usages of getConstrainedTypeAtLocation.

Additional Info

No response
@kirkwaiblinger kirkwaiblinger added triage Waiting for team members to take a look repo maintenance things to do with maintenance of the repo, and not with code/docs labels Dec 30, 2024
@JoshuaKGoldberg JoshuaKGoldberg added accepting prs Go ahead, send a pull request that resolves this issue and removed triage Waiting for team members to take a look labels Dec 30, 2024
43081j added a commit to 43081j/typescript-eslint that referenced this issue Dec 31, 2024
@43081j
chore(eslint-plugin): use getConstraintInfo in no-unnecessary-templ…
82bac17 
…ate-expression

Switches the `no-unnecessary-template-expression` rule to use
`getConstraintInfo` internally.

Related typescript-eslint#10569
@43081j 43081j mentioned this issue Dec 31, 2024
Merged
3 tasks
@kirkwaiblinger
Copy link
Member Author

PSA with important context for contributors looking to work on this: The fundamental concern in #10438 was that we haven't been extremely consistent about handling unconstrained generics correctly throughout our rules. The new api, getConstraintInfo, forces you to handle the case of an unconstrained generic separately (by returning an undefined constraint type). Therefore, as part of this work, we'll want to ensure that we have test coverage for all 3 of

  • constrained type parameter (eg function f<T extends string>(x: T){})
  • unconstrained type parameter (eg function f<T>(x: T){}) <-- this has been especially sparsely tested
  • nongeneric (eg function f(x: string){})

wherever getConstraintInfo is used (and these cases are sensible/reachable). Existing tests may or may not currently handle all these possibilities.

43081j added a commit to 43081j/typescript-eslint that referenced this issue Jan 1, 2025
@43081j
chore(eslint-plugin): use getConstraintInfo in no-unnecessary-templ…
21be05c 
…ate-expression

Switches the `no-unnecessary-template-expression` rule to use
`getConstraintInfo` internally.

Related typescript-eslint#10569
This was referenced Jan 1, 2025
Draft
Draft
Draft
@kirkwaiblinger kirkwaiblinger added the good first issue Good for newcomers label Jan 3, 2025
JoshuaKGoldberg pushed a commit that referenced this issue Jan 3, 2025
@43081j
chore(eslint-plugin): use getConstraintInfo in no-unnecessary-templ…
c7154bf 
…ate-expression (#10578)

Switches the `no-unnecessary-template-expression` rule to use
`getConstraintInfo` internally.

Related #10569
@kirkwaiblinger kirkwaiblinger added the blocked by another issue Issues which are not ready because another issue needs to be resolved first label Jan 3, 2025
@kirkwaiblinger
Copy link
Member Author

Marking this as temporarily blocked pending the outcome of #10606, since we may need to change the API of getConstraintInfo to avoid another class of bugs.

@kirkwaiblinger kirkwaiblinger removed good first issue Good for newcomers accepting prs Go ahead, send a pull request that resolves this issue labels Jan 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
blocked by another issue Issues which are not ready because another issue needs to be resolved first repo maintenance things to do with maintenance of the repo, and not with code/docs
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@JoshuaKGoldberg @kirkwaiblinger
0