📎 Implement nursery/useExplicitTypes - typescript-eslint/explicit-module-boundary-types and typescript-eslint/explicit-function-return-type

[Conaclos]

Description

The rule will cover:

• TypeScript's isolated declarations constraints.
  Cover explicit-module-boundary-types
• explicit-function-return-type
• explicit types on all methods and properties.

This rule must not conflict with noInferrableTypes.

Some context here.

[barthuygen]

This is exactly the what I'm missing, is there any prospect on when this might be implemented?

[ematipico]

@barthuygen

We refrain from giving dates, deadlines and such because we aren't a company and we develop things using the small resources we have.

If you're willing to see this shipped "faster" than the others, you can always help us financially: https://github.com/biomejs/biome/blob/main/GOVERNANCE.md#financial-contributions

Or willing to implement the feature yourself.

[dreamorosi]

Hi @ematipico - about the sponsorship:

• what would be an appropriate amount of sponsorship that would secure the implementation?
• once sponsored, what would be the estimated timeline for the feature to land in a biome version?

I can't commit to it yet, but having a discrete amount and timeline would definitely help me make a case.

[ematipico]

@dreamorosi I believe we document everything inside our governance document. I suggest to reach out to us in #funding

[dreamorosi]

Hi @ematipico thanks for the reply - None of the links to Discord in the Governance document worked for me, maybe the invite link has expired. I was able to join through another link in the Contributing doc.

[RayanMoarkech]

+1 for explicit-function-return-type

[firxworx]

No kidding the explicit-function-return-type rule is the singlemost important blocker from me not ditching eslint entirely for biomejs... that plus better monorepo support but I know that's in the works. I tried biome and it is amazingly fast and nice.

Importance

TypeScript runs better and faster with explicit return types especially in large codebases, and its been known to make unexpected random performance issues disappear.

Stylistically I love it, it brings the rigour of strong-typed languages like java and makes code much easier to review and test when every function signature is a declaration of the "data in + data out" and an explicit statement of the developer's intent.

I've even watched it prevent bugs in React components during pair sessions (where this rule is sometimes accused of being annoying) e.g. if a component may conditionally return null that has to be part of the return type in addition to JSX.Element.

Suggestions

I understand the first priority is getting this rule in.

IMHO to take it to another level would be to have some more customization capabilities for it beyond what eslint provides and perhaps a "lever or knob" to control it for trivial arrow functions.

Perhaps dreaming now: a level of React awareness would be fantastic e.g. as I don't think cleanup callbacks and the like (always void) need to be declared. While I appreciate it, others would love to turn it off for React component files e.g. tsx but keep it for ts.

Perhaps to pull some of the dream requirements off as a general feature there could be a way to configure with custom patterns/regexes.

[kaykdm]

I have implemented the base cases of typescript-eslint/explicit-function-return-type rule. Here are the remaining TODOs, as discussed in the PR:

• Implement the base cases of this rule - feat(linter): implement useExplicitFunctionReturnType #3990
• Support higher-order functions (allowHigherOrderFunctions in typescript-eslint) - feat(useExplicitFunctionReturnType): support higher-order function #4117
• Support typed function expressions (allowTypedFunctionExpressions in typescript-eslint) - feat(useExplicitFunctionReturnType): support typed function expressions #4174
• Support direct const assertions in arrow functions (allowDirectConstAssertionInArrowFunctions in typescript-eslint) - feat(linter): support direct const assertions in useExplicitFunctionReturnType rule #4027
• Support callbacks without return types (allowExpressions in typescript-eslint) - feat(linter): support allow expressions #4036

[nazarhussain]

I implemented allowArrowFunctions which behaves different than allowExpressions. The later restrict the rule only for expressions, but allowArrowFunctions is wider and more general for arrow functions.

Would suggest to include it as an additional feature than eslint-rule parity. #4233 What would you think?

[Conaclos]

@nazarhussain
Could you give some examples that are not covered by allowExpressions and are covered by allowArrowFunctions? Is allowArrowFunctions compatible with TypeScript's isolated declarations?

[nazarhussain]

When an object is composed with functions, the expression definition does not apply. Check this snippet.

You will notice that allowExpressions does work when a function is passed as argument, but not when a function is used as object attributes.

[Conaclos]

@nazarhussain Thanks for the details. I think it is worth adding these cases to the rule. However, this doesn't require an option, this should be the default behavior.

[nazarhussain]

@Conaclos Thanks for feedback. I will update my PR accordingly and extend the rule without adding a new option.

[nazarhussain]

@Conaclos I updated the PR, please review when available #4233

[aripalo]

IMO this rule should allow some configuration.

Use case: When working with tsx components, having to define the return type for every component is kinda tedious. I understand that some people may want to do this, but I think it would be beneficial to have an option to ignore certain user-defined return types (like JSX.Element).

[aripalo]

I know I can use the overrides functionality (and I probably will for now) to exclude .tsx files from this rule. BUT that's not exactly a good option either, because .tsx files could still have other functions to which I'd like to specify a return type.

[firxworx]

While I agree with @aripalo that more granular customizability would be a nice feature, I think it should be a separate issue / PR and not hold up this one, which adds a really important eslint feature for many teams and users.

When it comes to the idea of the potential for finer grained control, my mind also spins with ideas of how this could look...

Like maybe an ignore pattern for certain variable or function names to ignore "special" exports associated with modern frameworks (e.g. such as a remix / rr7 loader, etc.)

Such ideas and implementations are ultimately tangential to reaching the goal of a solid eslint replacement with explicit module boundaries and explicit function return types.

Its not a blocker if extra frills are not there!

Many thanks to nazarhussain for pushing this forward.