[explicit-function-return-type] only apply to exported functions about typescript-eslint HOT 3 CLOSED

(I think) It would be pretty trivial to support just these cases, at least to start.

• export (default) function
• export (default) class methods
• export const = {}
• export default {}

Most of those cases are just a simple matter of checking the parent (or the parent of the parent)

from typescript-eslint.

I'm agree with the idea behind this. Explicitly typing the module boundaries is a great practice. It'd be good to have this as an option on this rule.

That being said... my issue with doing this is that it will not be easy to achieve at all because of the cases that have to be handled. To name a few:

//
export function direct directNamedExport() {}

//
export default function defaultExport() {}

//
function indirectNamedExport() {}
export { indirectNamedExport }

//
export default {
	defaultObject() {}
}

//
export const directNamedObject = {
	onDirectNamed() {}
}

//
function onIndirectNamed() {}
const indirectNamedObject = {
	onIndirectNamed,
}
export { indirectNamedObject }

//
function viaVariableReference() {}
export const variableRef = viaVariableReference

// 
function viaDoubleVariableReference() {}
const variableRefOne = viaDoubleVariableReference
export const variableRefTwo = variableRefOne

// etc...

Because we are dealing with an AST; it's rather hard to tell exactly what is exported.
Most of the cases really boil down to this: every time you encounter a named/default export, you have to recursively unroll the references until you figure out if it's a function, and then check the signature. If you encounter an object you have to iterate the props to do the same process.

For this reason alone my recommendation would be to not bother with the rule; it'd probably be a maintenance nightmare due to edge cases.

That being said, I'm not familiar with exactly what the TS parser services will give us. Someone better versed in them might be able to inform if they'll help at all here?

from typescript-eslint.

I'm personally fine, at least as a first step, to just support export (default) function as a start - that would cover most cases I think (except for object literals, but maybe those should be interfaces anyway?).

from typescript-eslint.