[explicit-function-return-type] only apply to exported functions #65
Comments
|
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. 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? |
|
I'm personally fine, at least as a first step, to just support |
|
(I think) It would be pretty trivial to support just these cases, at least to start.
Most of those cases are just a simple matter of checking the parent (or the parent of the parent) |
…rtedFunctions option (typescript-eslint#65)
…rtedFunctions option (typescript-eslint#65)
…rtedFunctions option (typescript-eslint#65)
…rtedFunctions option (typescript-eslint#65)
…tedFunctions option (typescript-eslint#65)
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
…ipt-eslint#65) This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio n to class methods.
I'd like to propose a change to an existing rule.
Description
It can be unnecessarily verbose to type every single functions return type, but I'd love to enforce typing of functions exported from a file. I find that then the type errors are closer to the actual error, rather than having bubbled up multiple functions, while still being less onerous to do. Thoughts?
The text was updated successfully, but these errors were encountered: