Skip to content

Enforce explicit function return types to stabilize API #891

Description

@tbouffard

Is your feature request related to a problem? Please describe.

We want to make our public API more stable.
Right now, TypeScript infers the return type of functions automatically. It's convenient, but it means a change in implementation can silently alter the return type. That’s risky: it could introduce breaking changes without any warning — and without any error from the type checker or linter.

We prefer to fail early, during development.

Describe the solution you'd like

Enable the ESLint rule [@typescript-eslint/explicit-function-return-type](https://typescript-eslint.io/rules/explicit-function-return-type/) in our config.
Or use the isolatedDeclarations TypeScript compiler option: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-5.html#isolated-declarations.

We will enforce explicit return types, at least for exported functions and methods. This way:

  • the intended API is more visible,
  • future refactors are safer (type changes are caught),
  • and it improves stability for users depending on the typings.

Describe alternatives you've considered

We’ve considered using tools like api-extractor to snapshot or validate API types, but it adds complexity and tooling overhead.
Using ESLint or TSC option is a simple and effective step for now.

Additional context

From the rule’s rationale:

Functions in TypeScript often don't need to be given an explicit return type annotation. Leaving off the return type is less code to read or write and allows the compiler to infer it from the contents of the function.
However, explicit return types do make it visually more clear what type is returned by a function. They can also speed up TypeScript type checking performance in large codebases with many large functions.

Let me know if you want this to apply only to exported functions, or also internal ones.
We can also consider applying it gradually across folders.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions