Codecov Report

Merging#87 intomaster willincrease coverage by<.01%.
The diff coverage is100%.

@@            Coverage Diff             @@##           master      #87      +/-   ##==========================================+ Coverage   95.08%   95.09%   +<.01%==========================================  Files          49       49                Lines        2483     2487       +4       Branches      371      371              ==========================================+ Hits         2361     2365       +4  Misses         73       73                Partials       49       49

@armano2 Conflicts now just FYI

i don't like name of option here:allowInCallExpression is not fully ok, this will allow to use type assertion in new and call expression....

allowAsParameter?

There may be another use case here that needs consideration: return values.

Consider the following code:

// Returns either Thing or Partial<Thing>functiongetNewOrExistingThing(id?:number):Thing|Partial<Thing>{// if an id was not passed, return a Partial<Thing> (new)if(isNaN(id))return{ ...}asPartial<Thing>;// otherwise, return a Thing (existing)return{ ...}asThing;}

Unlike theconst x = { ... } as T ->const x: T = { ... } case, there is no equivalent workaround for return values.

Would the proposedallowAsParameter option also allow for the return value scenario above, or should there be aallowAsReturn option as well?

Since TypeScript uses a structural type system, the returned object will pass the type check as long as it has all the required properties ofThing orPartial<Thing>.

@scottohara Following on from@j-f1 comment, I am not sure about your example.

Let's take the example where there is no extraPartial involved for simplicity:

https://typescript-play.js.org/#code/PQ18ZXTMAQDkDyAVOBxJSAiAoXAlgHYAuApgE4BmAhgMZlwoAWxA5nAN65y9xUB7AQC44AIyEAbMjSIBuHnzE0KoiQOmyFAX3xUArkTokCAonDZkSCMgHckFAKIAPAgGcTRNi3YAKAJSiPl5cihRW+hTm3Hx8giJwJBT6ZIracDRuTKxeOvh0Zh6JORwAvBZWNvZOrh7swWwBCriwrW3tHXAAQo4oKI4ASvjE5NT0jA2hsfFqUjLyirzKquJzWri6uAZGJmYV1nYOLu6e3iUATAFBJVNwBURFJNfscOUxsfxCokkpaQq84RIkXMJDyuHujwur32VSOtVODSaQA

I would say that the second form is what you would do - allowing the type assertion is really not desirable in most cases, as it opens you up to potential future issues after refactorings, and so having a linting option to allow it doesn't seem to make sense to me. Please let me know if I am missing something.

In the rare case where you do need the type assertion behaviour as a return value, using aneslint-disable comment is probably a good thing - it shows to other readers of the code (including yourself in the future) that you acknowledge you are overriding linter feedback and helps flag it up as an unusual case.

Let me know what you think

@JamesHenry - thank you for your playground example, and as usual you are 100% spot on.

The second form does indeed (at the cost of one extraconst declaration) both avoid the need for a type assertion on the return value,and conveys the developer's intent far better.

I'll cut a full release after this goes in, we've merged in quite a few fixes since v1 now

@JamesHenry its way easier now to test and fix issues (when we have control over all packages)

Awesome, that was the hope :) I am very happy with how our monorepo is shaping up!

I've releasedhttps://github.com/typescript-eslint/typescript-eslint/releases/tag/v1.1.0