Tslint: Add quick-fix for "typedef" rule

[alber70g]

Feature request

Is your feature request that we implement a new rule?
No

Is your feature request related to a problem? Please describe.
When working with Typescript it's very nice that the compiler infers a lot of types for me. However, I usually add the return type to functions in order to preserve the signature when refactoring functions. This way I don't end up having a problem when I accidentally change the return type because I return something different.

Would it be possible to add the return type automatically, since the AST knows what type I'm returning.

Example when refactoring this:

function addText(input: string) {
  return input + " this is me";
  // When refactoring this to what's below `input.length`, 
  //   you get the error on line with `toUpperCase`. 
  // However, I'd rather have it to be on the return type that's 
  //   currently being inferred by Typescript
  return input.length;
}

const x = addText("Albert");

const y = toUpperCase(x);

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
n/a

Additional context
Request also posted here, but was pointed to the tslint --fix as possible solution: https://github.com/Microsoft/TypeScript/issues/25141

[giladgray]

🤔 not convinced this rule would actually be helpful--i can easily see a case where it puts a return type that is not what you expected, such as while you're writing the function. this could result in incorrect code, which is contrary to the linter goal.

[giladgray]

I would not rely on a tool to specify the return type but rather define the return type manually as I write the function signature. then I know my code is wrong until it passes what I wrote. rather than the inverse that you propose, where the linter assumes your code is correct.

[JoshuaKGoldberg]

Agreed with giladgray. One fun example:

export type Color = "red" | "blue";

export function getDefaultColor() {
    return "red";
}

What should getDefaultColor() create? Suppose it's used later on:

import { Color, getDefaultColor } from "./colors";

let color: Color = getDefaultColor();

This seems like something we wouldn't be able to tackle well in TSLint core. Closing for now, but anyone has justification for ways we could do this well, please do comment here!

[anka-213]

@JoshuaKGoldberg Typescript would infer that it is a string and complain about that the usage even when you leave it undeclared. The only difference is that the types that typescript infers are made explicit, so the user can see that they were wrong and correct them.

I don't think we can assume that a quick fix should be the correct fix for all possible use cases. But it would at least not make the situation worse in this case.

---

The way I would use this is mostly to save typing and sometimes to save some thinking, but I would always inspect the generated type to check that it conforms with what I would expect. I use the corresponding feature in Haskell all of the time, but I do see that the situation there is a bit different.