@evanbelcher
Specifying a type is a must for any library / public api. For private functions, I usually still specify if it's a complicated function as it's a nice sanity check that your function is returning what you think it is, especially if you're writing the type before you implement the function. For simpler functions, I usually skip it
@AntonioSantana-ll8il
I think it dependes, as You said, make a lot of sense in apps that use react . I am an angular developer, since we don't usually return components it is really helpful to always specify the returned object type of a function. Makes easier to maintain the code and even refactor it since You know no matter the Magic You make inside of the funcion You know what it should return
@rumble_bird
My take on this is when you return an object and `satisfies` keyword applies to this case, then you should add a return type instead of using `satisfies`. For example when you return POJO from a function. On the contrary when you return value which is either created with `new` or return from other function with a known return type or trivially inferable named one, you shouldn't.
@richmerch
If I'm creating a library, I tend to add the return type. But if I'm just creating a helper function that formats a string for example, I don't bother.
@tylim88
Unless your type logic is complicated, Infer is better because machine almost always more accurate and precise than human. The notable issue with inference is it is slower
@anhdunghisinh
I usually make return types if the function return a fresh new object with multiple properties that its type have never been declare before. It helps me managing which properties are being used, which one aren't, so that i can trim down the logic when i don't need those code anymore. I also use return type if the type of value being return are really messy due to it was form up by a complicated union type.
@classic-25
After working on large scale projects with multiple teams I would say hands down always add as much types as you can cause it reduces the type lookup ts has to do to provide intellisence for your code. In small project it really doesn’t matter
@pupfriend
I only add return types when it returns void.
@goodboyneon
I let typescript infer it most of the time, and only explicitly specify a return type when I can define a type more specific than the inferred one (ex. number[] vs any[]). HOWEVER, I do always explicitly set a return type when writing library code
@juanparadox
I've always gone with the thought that writing less types in TypeScript and letting TypeScript do what it does best is the way to go. So, no, I don't set return types. Inference is preferable imo.
@duongphuhiep
lets TS infer the return types means that you don't really know (or care) about the shape of your output.. But if you do (and care) then avoid to rely on TS Inferences, explicitely create types for the return result is not that time-consuming.. with plenty of benefits, especially for long run.
@TheSourceOfEvil
Neither is ideal, there should be an option to configure linters somewhere in between
@ArmandRobotson
It's great that machines are now learning human language.... hopefully tyrannical mindless coding ends once and for all....and sound logic becomes native to programming...
@EricSundquistKC
Wow, not used to seeing Matt be wrong! At least specify it on expected functions.
@AmrouBouaziz
yeah, or use Angular instead 🤣💀
@devsami
I feel like if you have some core utils, you should type the return, given that the functions don't change very often.
@anton4488
No, this is horrible. This rule should be turned on for team projects. Other people here in the comment section explained it in greater details.
@steamer2k319