Thanks for the PR,@controversial!

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	239f3df
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/6761bd5ffc147e0008e6d79d
😎 Deploy Preview	https://deploy-preview-10461--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 92 (🟢 up 14 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.

☁️ Nx Cloud Report

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

📂 See all runs for this CI Pipeline Execution

Sent with 💌 fromNxCloud.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.79%. Comparing base(b2ce158) to head(239f3df).
Report is 10 commits behind head on main.

@@           Coverage Diff           @@##             main   #10461   +/-   ##=======================================  Coverage   86.78%   86.79%           =======================================  Files         445      445             Lines       15366    15376   +10       Branches     4475     4478    +3     =======================================+ Hits        13336    13346   +10  Misses       1675     1675             Partials      355      355

With respect to a custom error message,@kirkwaiblingersuggested:

As a first pass, I think we could just model it after the TS error message?

Unsafe type assertion: 'Object' is assignable to the constraint of type 'CustomObjectT', but 'CustomObjectT' could be instantiated with a different subtype of constraint 'Object'.

In the original PR of this rule,#10051, a discussion about the appropriate verbosity of the error messageresolved to omit any types other than theexplicitly written type from the error message in order to prevent excessively verbose errors.

With that in mind, I’m starting out with the following error message:

Unsafe type assertion:the original type is assignable to the constraint of type 'CustomObjectT', but 'CustomObjectT' could be instantiated with a different subtype ofits constraint.

I’m happy to amend this message to be more verbose if we decide to go that way, though!

Thanks so much for the thoughtful review@kirkwaiblinger !!

I added the test cases from your playground and addressed the missing cases. For the missing case ofunconstrained type parameters, I added another message to match the one Typescript uses:

Unsafe type assertion: '{{type}}' could be instantiated with an arbitrary type which could be unrelated to the original type.

Here’s an updatedplayground link!

functionparameterExtendsOtherParameter<T,VextendsT>(x:T,y:V){x=y;yasT;// allowedy=x;xasV;// banned; generic arbitrary subtype <-- currently has wrong error message.}

Merged the latestmain to resolve merge conflicts from#10472

When you get a chance, let me know if there’s anything else you need from me@kirkwaiblinger :)

My first impression was that this case should raise the “x is assignable to the constraint of V” message. However, my current implementation instead says “V could be instantiated with an arbitrary type.”Notably, though (and somewhat to my surprise) this behavior is consistent with the message that Typescript gives for this case, so I think it’s probably ok as-is?

I feel strongly that TS is wrong here, sinceV plainly cannot beunrelated toT. It's guaranteed to be a subtype ofT, since...V extends T 🤷 . However, I agree that it makes sense to match their behavior here, and we can follow up by filing an issue to TS if we like. (Feel free to do this if you're interested! Otherwise I probably will at some point 🙂)

Iadded a newparameterExtendsOtherParameter test where T isnot unconstrained; here, both TypeScript (for assignment) and my implementation raise “is assignable to the constraint of V” like I expected. I renamed the original test toparameterExtends**Unconstrained**Parameter.

🎉

cleanup completed! thanks again for your thoughtful reviews, excited to have this merged at some point :)