ESlint: Require explicit return types on exported functions, yes or no??
Per Theo's video I'll post below and the well articulated logic within, it's best to avoid using explicit return types whenever possible.
I just jumped in on a codebase that has eslint rules that yell at me when I don't explicitly type the return type of function's that are exported ie
export function foo() and export default function. Should I (suggest we) disable this and let the return types be inferred as Theo suggested of functions in the below video? Specifically I am asking about this eslint rule: https://github.com/typescript-eslint/typescript-eslint/blob/v4.33.0/packages/eslint-plugin/docs/rules/explicit-module-boundary-types.md
https://www.youtube.com/watch?v=I6V2FkW1ozQ&t=495s13 Replies
Not if you just jumped in. Best you can reasonably do is ask why it's there. Either you learn something about a specific problem this is solving, or you can start a discussion and maybe others will start to see it your way.
(Unless you were specifically brought in to be a typescript expert or something)
More like the second one and the code is very minimal and there's a lot of bloat and boiler plate stuff in the repo that doesn't seem to do anything. So I'm trying to clean stuff up rn.
But when I look at the eslint config of create-t3-app app's there is no reference to anything like this
'@typescript-eslint/explicit-module-boundary-types': 'off',
so idk why it doesn't flag it in t3 apps
But I guess you're confirming it's an antipattern to use retun types...They're nice for libraries where you want TS to yell at you if you're going to break your contracts.
what?
Oh you like return types??
So you're taking the opposite side as theo on this one?
For libraries you are sharing outside your team
Internal or app code go with inferred returns for sure
Why?
Have you watched the video?
If you want a video, here's an explanation of why to use explicit return types in libraries. https://youtu.be/nwSe95uFN8E?t=152
Matt Pocock
YouTube
Don't use return types, unless...
Your default attitude towards return types should be 'don't use them', unless one of three things are true:
- You're writing a function with multiple branches
- You're building a library
- You have a specific TS perf concern and you're banging your head against the wall
Become a TypeScript Wizard with Matt's free TypeScript Course:
https://ww...
I don't want a video per se, but I'll watch this one
Do you have an explanation or you just gonna leave it to Matt?
Matt is a top notch typescript resource. I recommend all his stuff.
I can give you similar reasoning, I don't really have much to say that Matt doesn't
Short answer is it makes things better for the consumers of your code
Matt's content is high quality. His pricing and email marketing is utterly abusive.
I have actually seen that video before
Because of performace?
Heh, I guess I should say all his free stuff
Also, you can export meaningful types that would never be inferred
I bought his shit, it's good. Extremely overpriced, and I was blown away that he's adding another module that he's offering the low low price of $170 to you because you bought the $600 lifetime access to his platform. It's fucking crazy what a dick / moron ...
Like I am so confident he would make a lot more money if priced it less the $300
the content is really nice tho
I especially like Typetransforms workshop
Well I could just assign whatever get's returned to this meaningful type with an
as for example
and then I don't have explicit return types anywhere in my code.... which feels good and consistent
Btw I am building an external libraryI'd rather annotate my function than start throwing as around but at the end of the day it isn't a huge difference