Consider @typescript-eslint/explicit-function-return-type

[sybereal]

https://typescript-eslint.io/rules/explicit-function-return-type

It's an extremely strict and potentially excessive requirement, but it brings a lot of value. The key benefit is that mistakes pertaining to a function's return type cause errors within the function, and not at the usage site, which might be in an entirely different file or different package even. This is especially relevant when accidentally using (slightly) inconsistent return types. TypeScript won't care and just infer the return type as the union of all return statements' types, but users of the function will be very confused.

A less strict alternative is explicit-module-boundary-types, which reduces the requirement to exported values and functions, retaining the lion's share of the value the rule brings, while reducing friction for internal helper functions, callbacks, etc..