Thanks for the PR,@WoodyWoodsta!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently onhttps://opencollective.com/typescript-eslint.

I've specifically left out unit tests for this, as it doesn't appear that any of the fixtures foreslint-plugin include .mts or .cts files. It seems like something which should require test-wide/project-wide consensus. Please correct me if I'm wrong!

☁️ Nx Cloud Report

CI is running/has finished running commands for commit1ab20aa. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

Sent with 💌 fromNxCloud.

I've noticed two things:

• My changes don't address the problem (at least in my project via linking)
• I can add tests as you can specify thefilename on theRuleTester. Will do that now.

✅ Deploy Preview fortypescript-eslint ready!

Name	Link
🔨 Latest commit	1ab20aa
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/64b492583501ff00083d9842
😎 Deploy Preview	https://deploy-preview-6795--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to yourNetlify site configuration.

@bradzacher I'm trying to understand why the proposition you made which was simply to use thegetScriptKind util as a "fix", becausegetScriptKind still interprets.mts and.cts files asTS files, notTSX.

Regardless, there was no logic in the rule which checked for jsx/js, only the fix method. So I've added a new util to serve as a bypass for this rule. I have no idea if this is the correct approach: to me it doesn't seem elegant.

Codecov Report

Merging#6795 (1ab20aa) intomain (d67fd6d) willincrease coverage by0.00%.
The diff coverage is100.00%.

@@           Coverage Diff           @@##             main    #6795   +/-   ##=======================================  Coverage   87.47%   87.47%           =======================================  Files         379      379             Lines       13228    13234    +6       Branches     3905     3906    +1     =======================================+ Hits        11571    11577    +6  Misses       1279     1279             Partials      378      378

@bradzacher To sum up your comments and relate to the issue:

Original Issue

• <T> requires disambiguation inmts,cts and JSX language variant files
• <T extends any> as a disambiguation reportsno-unnecessary-type-constraint inmts andcts files
• rule fix,<T extends any> -><T,>, is stripped of the dangling comma with at leastprettier as a formatter returning it to the place of needing disambiguation

Fix

• Only reportno-unnecessary-type-constraint for<T extends any> in files which do not require disambiguation (everything other thanmts,cts and JSX language variant files)

No changes to eslint fix required.

Let me know if this sounds correct.

Of course this could also be resolved in some way in formatters (i.e. to not strip the dangling comma here), but:

• it's a matter of opinion which of<T,> and<T extends any> is "better"
• stripping dangling commas from single-line argument listsexcept for in this case requires quite a lot of contextual awareness which I'm not sure whether these formatters have 🤷

rule fix, -> <T,>, is stripped of the dangling comma with at least prettier as a formatter returning it to the place of needing disambiguation

If prettier is stripping the syntactically necessary comma when formatting a.cts/mts file, then that's a prettier bug to be reported and fixed.

It has already been reported:prettier/prettier#14518

stripping dangling commas from single-line argument lists except for in this case requires quite a lot of contextual awareness which I'm not sure whether these formatters have

Formatters are powered by the AST - they know exactly and unambiguously that<T,>() => {} is an arrow function with a type parameter declaration because the parser has encoded that in the AST.

The formatter then decides how to print the code from the AST - if it decides to prints the type parameter on a single line, its trivial to also insert the comma.

Only report no-unnecessary-type-constraint for in files which do not require disambiguation (everything other than mts, cts and JSX language variant files)

This is not correct, no.

The rule shouldalways report on the unnecessaryextends any and the fix is to remove it in.ts files, and replace it with a comma in.tsx/cts/mts files.

The current rule behaviour is toalways report - but the erroneous behaviour is that it removes it in.cts/mts files. Thus the fix is more or less to qualify those extensions as TSX files so that they are treated the same way, and receive a comma.

Formatters are powered by the AST

@bradzacher Ok you confirm what I thought. So if I understand correctly, there is actually nothing to do here intypscript-eslint? 😆

Mylast comment describes the change we need to make to the rule - we need to fix to<T,> inmts/cts files.

@bradzacher Hopefully I've now understood. Please see6bfccc6

@bradzacher Any thoughts on the above?

@bradzacher is this still something you have time to review?