Tslint: Support an option like `"typedef": "never"`

[manuth]

Rule Suggestion

Is your rule for a general problem or is it specific to your development style?

This suggestion is about an existing rule which is called typedef and is a general problem for everyone especially the ones who wants to keep their code consistent.

What does your suggested rule do?

I suggest to add an option like "when": "never" and "when": "required" to the typedef-rule.
This would either force the user to never define types or, which is ways more important, to only define types when typescript can't figure them out on its own which is when the noImplicitAny-rule of tsc reports errors.

This is pretty useful to keep the code consistent and to make it looking the same no matter where.

List several examples where your rule could be used

"when": "always"
This should act the same like "typedef": true

"when": "required"

private name: string;

/* This should report an error because TypeScript
 * already knows its type from `this.name`
 *                v    */
public Name(): string
{
    return this.name;
}

let name: string = "Hello World";
//           ^
// This should report an error, too because also here TypeScript implicitly knows what type it is

Additional Context

https://github.com/Microsoft/TypeScript/issues/27261 Maybe reading this issue will help you to understand the use-case a little better

[JoshuaKGoldberg]

only define types when typescript can't figure them out on its own

The never option would be counterproductive in many situations now that type unions are available.

let color: "red" | "blue" = "red";
let nextId: number | undefined = numbers[0]; // numbers: number[] or [number, number]

...but having an option that indicates not to add the types when it doesn't change the type sounds like a good idea.

[manuth]

Ich hat's a good point!
This is exactly what I'm looking for.

Do you think it is possible to implement such an option?

[JoshuaKGoldberg]

I do 😊 as was mentioned in #4188, the typedef rule isn't what it used to be. TypeScript's type inference system is now smart enough that manual type annotations tend to be much more annoying than helpful. Allowing the rule to recommend _not_ having them might need the type checker as an optionally typed rule, but seems reasonable.

[manuth]

oh uhm... is it, by the way, up to me to write a proposal or is a TSLint-team member going to take care of it?

[JoshuaKGoldberg]

@manuth up to you 😊

[manuth]

I just browsed through some issues which don't have the "Needs Proposal" label in order to find out what a proposal is.

Is it PR containing changes in order to implement my suggestion?

[JoshuaKGoldberg]

Not yet - we would just need to see in this issue a clear proposal of how you'd like to tackle these changes. In this case, I think it's just unclear when the "never" option would or wouldn't apply. If you could clarify that, ideally with some examples of when it would give a complaint and some examples of when it wouldn't, that should be good enough.

Does that clear it up?

[manuth]

Alright!
I'll give it a go this weekend. Thanks for your explanation.

[JoshuaKGoldberg]

☠️ TSLint's time has come! ☠️

TSLint is no longer accepting most feature requests per #4534. See typescript-eslint.io for the new, shiny way to lint your TypeScript code with ESLint. ✨

It was a pleasure open sourcing with you all!

[JoshuaKGoldberg]

🤖 Beep boop! 👉 TSLint is deprecated 👈 _(#4534)_ and you should switch to typescript-eslint! 🤖

🔒 This issue is being locked to prevent further unnecessary discussions. Thank you! 👋