Thanks for the PR,@ronami!

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.

✅ Deploy Preview fortypescript-eslint ready!

Name	Link
🔨 Latest commit	02c3124
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/678bf9d5cb6ba700083a54a7
😎 Deploy Preview	https://deploy-preview-10552--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 94 (🔴 down 4 from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 98 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

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

View yourCI Pipeline Execution ↗ for commit02c3124.

☁️Nx Cloud last updated this comment at2025-01-18 19:26:13 UTC

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.18%. Comparing base(31be053) to head(02c3124).
Report is 29 commits behind head on main.

@@            Coverage Diff             @@##             main   #10552      +/-   ##==========================================+ Coverage   87.15%   87.18%   +0.02%==========================================  Files         448      448                Lines       15576    15611      +35       Branches     4551     4562      +11     ==========================================+ Hits        13575    13610      +35  Misses       1645     1645                Partials      356      356

Thinking some more about this: The rule will add a type annotation whenever literal widening happens, regardless of whether the property is mutated in the constructor or not.

I'm slightly leaning towards adding a type annotationonly when literal widening happensand the property is mutated in the constructor (in addition to an initializer).

Thinking some more about this: The rule will add a type annotation whenever literal widening happens, regardless of whether the property is mutated in the constructor or not.

I'm slightly leaning towards adding a type annotationonly when literal widening happensand the property is mutated in the constructor (in addition to an initializer).

I'm not sold on this. My concerns are

• It increases the level of surprise for the user by adding a special case within a special case
• It changes the public API of the class. This may absolutely be adesired consequence in many cases! But it may also be breaking. This tilts the scales for me more towards the conservative option of conspicuously preserving the original type, and letting the user easily opt in explicitly to the narrower one by removing the type annotation.

My order of most to least preferred approaches for this case would be

1. (currently implemented) Autofix with original, widened type
2. Don't autofix. Offer suggestions for both possibilities (very close second, could probably be argued either way between 1 and 2)
3. Autofix with narrowed type.

But I'll defer to you guys if those points don't sway opinions. It's not a big thing.

Thinking some more about this: The rule will add a type annotation whenever literal widening happens, regardless of whether the property is mutated in the constructor or not.
I'm slightly leaning towards adding a type annotationonly when literal widening happensand the property is mutated in the constructor (in addition to an initializer).

I'm not sold on this. My concerns are

• It increases the level of surprise for the user by adding a special case within a special case
• It changes the public API of the class. This may absolutely be adesired consequence in many cases! But it may also be breaking. This tilts the scales for me more towards the conservative option of conspicuously preserving the original type, and letting the user easily opt in explicitly to the narrower one by removing the type annotation.

My order of most to least preferred approaches for this case would be

1. (currently implemented) Autofix with original, widened type
2. Don't autofix. Offer suggestions for both possibilities (very close second, could probably be argued either way between 1 and 2)
3. Autofix with narrowed type.

But I'll defer to you guys if those points don't sway opinions. It's not a big thing.

Interesting take!

I didn't put much thought into it, but I agree that it can be confusing. It may seem unclear when the rule would add a type annotation and when it won't. Adding a type annotation whenever literals are involved simplifies how the rule behaves.

I considered the type changing a desired consequence, and I think it will be a breaking change pretty rarely, but it is possible.

For me, the increase in the level of surprise is a big reason to keep it simple and always auto-fix with the widened type 👍

Oh, I've misunderstood, sorry! - this ruleonly applies toprivate/#private propreties. So there isn't a public API concern! In that case I'm on board with only adding the annotation if they actually are mutated 👍

Oh, I've misunderstood, sorry! - this ruleonly applies toprivate/#private propreties. So there isn't a public API concern! In that case I'm on board with only adding the annotation if they actually are mutated 👍

@kirkwaiblinger I agree with your point that this change increases the level of surprise for the user by adding a special case within a special case.

I think both options are viable (always adding a type annotation for literals or only when literals are modified in the constructor), and the difference between the two is subtle. I was going back and forth between what I consider the optimal solution here, but I think I'm +1 for adding a type annotation only when necessary, even though it adds some surprise factor.

In my opinion, adding a type annotation may be already somewhat surprising, and adding it only when it's clear why it's necessary makes sense to me.

I've updated the PR to match this 👍