[consistent-type-assertions] Type assertions in return statements

[rfgamaral]

Hi there,

I wanted to follow up on this issue, but I can't comment there because the conversation is limited to collaborators.

I have this use case:

type FooBarProps = {
    withClassNames?: boolean
}

type FooBarBaseResult = { isSomething: boolean }

type FooBarResult<T extends FooBarProps> = T['withClassNames'] extends true
    ? FooBarBaseResult & { classNames: string }
    : FooBarBaseResult

function fooBarFn<T extends FooBarProps>({ withClassNames = false }: T): FooBarResult<T> {
    const isSomething = Math.random() < 0.5

    const result = withClassNames ? { isSomething, classNames: 'foo bar' } : { isSomething }

    return result as FooBarResult<T>
}

This is implemented with the consistent-type-assertions rule being enforced. But, as the referenced issue requested, I too would like to remove the intermediary result variable. However, the way the original issue described the intermediary result variable is different from this example. Unfortunately, I cannot do this:

function fooBarFn<T extends FooBarProps>({ withClassNames = false }: T): FooBarResult<T> {
    const isSomething = Math.random() < 0.5

    const result: FooBarResult<T> = withClassNames
        ? { isSomething, classNames: 'foo bar' }
        : { isSomething }

    return result
}

I get this error:

Since this is a TypeScript error, and not an ESLint one, what I'm looking to do is something like this:

function fooBarFn<T extends FooBarProps>({ withClassNames = false }: T): FooBarResult<T> {
    const isSomething = Math.random() < 0.5

    return withClassNames ? { isSomething, classNames: 'foo bar' } : { isSomething } as FooBarResult<T>
}

But I can't, the consistent-type-assertions rule does not let me.

The issue was closed with an update to the documentation to clarify that a new option is probably not needed. But I believe this use case proves otherwise. By no means, I'm an expert on this topic (either ESLint or TypeScript types), so I could be wrong, but for this particular use case, I don't think there's an alternative to the intermediary result variable.

With this discussion, I'm aiming for one of two things:

• Find a better way to work around the use case demonstrated above
• Or, reopen this issue, so that a new option is introduced for return statements

[kirkwaiblinger]

@rfgamaral
I think this might just be a parentheses issue. in return x ? y : z as T, the as T only applies to z.

If I understand the options and config you're using correctly, just wrapping the ternary in parentheses seems to solve the issue. (if not, consider putting a playground link with your options to help elucidate the issue)

https://typescript-eslint.io/play/#ts=5.4.3&showAST=es&fileType=.ts&code=C4TwDgpgBAYg9nAQgQwE4AVVzAZygXigG8AoKKAdwEtgALAYQBtkccA5ZAWwhwH4AuKACMEjCMgB2JAL4kSoSLAQpUKHBABKPAK6NgBYlCo4AynG50qEgOaCRcMZKiz54aPCRotOXcAA8ACpQEAAewBASACZ4HiqY2DgAfAYBANoA5NR0TCzsXDzpALrBYRHRUMCo2hBkULxKnqosmjp6UABkhgDGzKwc3DiCOJVW1s61grFoai0%2BenIAZtoSXcBUcBJQC8poMBKBJeFRMTsYWLiJABRElDQMvXkDBgvIjOrOggEAlJOn3r6BZKkchdDbDIymcwQSw2AwAWWQdAAdKhJJFzJcvlA-FAAAxIgCscnIqGh2lQm0uWXuuX6PDqhmMZgstFGABooD1aflBlB0ts4MI0OlnFBBDcmVCYWNpFiWA0VP89ICZEA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6MgeyeUuX0Ra0ipWgENkyRNHyUuqDAG1IU6B2iQANGHDZgUcZOmymAZSJJ0%2B1FsgcARgCtEZfABlK-aKPgAVEogBBCSkZOUtIb3gOAHcxZFpiUS8AW0RPSABfAF0dDJAMoA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

[kirkwaiblinger]

Though, now that I think about it, there's also a reasonable argument that that's just a bug in the rule that it works when asserting on a ternary, since many of the rules recur into ternaries, such as prefer-find and no-floating-promises

[rfgamaral]

@kirkwaiblinger Your example made me a realize I didn't post my final code sample in the OP (sorry about that). Here's a Playground link to demonstrate my issue: https://typescript-eslint.io/play/#ts=5.4.3&showAST=es&fileType=.ts&code=C4TwDgpgBAYg9nAQgQwE4AVVzAZygXigG8AoKKAdwEtgALAYQBtkccA5ZAWwhwH4AuKACMEjCMgB2JAL4kSoSLAQpUKHBABKPAK6NgBYlCo4AynG50qEgOaCRcMZKiz54aPCRotOXcAA8ACpQEAAewBASACZ4HiqY2DgAfAYBANoA5NR0TCzsXDzpALrBYRHRUMCo2hBkULxKnqosmjp6UABkhgDGzKwc3DiCOJVW1s61grFoai0%2BenIAZtoSXcBUcBJQC8poMBKBJeFRMTsYWLiJABRElDQMvXkDBgvIjOrOggEAlJOn3r6BZKkchdDbDIymcwQSw2AwAWWQdAAdKhJJFzJcvlA-FAAAxIgCscnIqGh2lQm2B5AhZgstFGABpauQkazLll7rl%2BjwOp0qdSoD0uflBlB0ts4MI0OkmQLpF9Zc4oCwGip-npATIgA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6MgeyeUuX0Ra0ipWgENkyRNHyUuqDAG1IU6B2iQANGHDZgUcZOmymAZSJJ0%2B1FsgcARgCtEZfABlK-aKPgAVEogBBCSkZOUtIb3gOAHcxZFpiUS8AW0RPSABfAF0dDJAMoA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

[kirkwaiblinger]

Thanks for sending the link!

(aside) Yeah, there you've disguised the conditional within the object literal, which lends support to the idea that the equivalent ternary form not being flagged is just a bug in the rule and not pertinent to the point of this discussion haha. Might file a followup.

My thought process goes like this

1. Why would you want this? This is exactly the type of type assertion that is unsafe and is meant to be caught by the rule. Use an eslint-disable comment and cast away if you like.
2. BUT, that logic would apply the same to the "allow-as-parameter" option
3. Which, FWIW, came into existence before the TypeScript satisfies keyword, so the motivation for that one existing at all seems obsolete, tbh.
4. But that's neither here nor there. If that option should be reevaluated, that's a separate conversation.
5. There is one important difference, as mentioned in the prior discussion, in that there is an extra reason to inadvertently use the type assertion on a return statement to specify the return type of a function in the presence of implicit return types. If (but only if) you enforce explicit return types in your codebase, this is moot.

I think there's a pretty good argument that "allow-as-parameter" option is basically the same as function parameters, with the (important) exception that there's yet an additional footgun if there isn't a return type on the function. Therefore, allowing return statement type assertions under allow-as-parameter would opt users into behavior that is more unsafe than it currently allows, which seems like something to avoid. So IMO that would necessitate creating a new option for permitting this behavior, if it's deemed sufficiently valuable to create a new option for.

I'm personally not really in favor, but that's largely because I don't personally like the "allow-as-parameter" in the first place, so that shouldn't be taken as an argument against the additional value that you are proposing for the return case.

---

With regard to the specific code you have, it seems like you should be able to write that without requiring a type assertion, since... it does satisfy the shapes of the types you've declared. I guess the issue is that TS doesn't narrow the generic. I wonder if there's a way to convince it to do so?

[kirkwaiblinger]

i guess another way to mitigate the return-type footgun would be to permit the type assertion only within functions that have an explicit return type already.

[rfgamaral]

@kirkwaiblinger Thank you for all that insight into the topic.

With regard to the specific code you have, it seems like you should be able to write that without requiring a type assertion

I believe there was another way, but it required them to duplicate the { isSomething } return value per two return branches, and I didn't want to do that because this is an example (my real code returns a lot more properties, and duplicating them didn't look so good).

Anyway, I realized there was actually no point to the withClassNames thing (for my real use case), and the whole type around it, so I've removed the whole thing, and now this problem is moot for me.

I really appreciate the time you took helping out, but so sorry for wasting it :(

[bradzacher]

Please note that we don't use discussions for technical support or bug reports.
If an issue is closed and locked then you can file a new issue referencing the old one and provide additional context, as you have done here.