arrow-call-signature Not working with arrow function missing type definition

[cjbarth]

Bug Report

• TSLint version: 4.3.1
• TypeScript version: 2.1.4
• Running TSLint via: CLI

TypeScript code being linted

let t: string[] = [
 "hi",
 "there"
];
let u: string = t.find((item: string) => { return item === "hi"; });

with tslint.json configuration:

{
 "rules": {
  "typedef": [
   true,
   "call-signature",
   "arrow-call-signature",
   "parameter",
   "arrow-parameter",
   "property-declaration",
   "variable-declaration",
   "member-variable-declaration"
  ]
 }
}

Actual behavior

I don't get a warning about the arrow function call signature not having a type defined.

Expected behavior

I should get a warning about the arrow function call signature not having a type defined.

[andy-hanson]

Looks like this behavior is intentional: it doesn't lint arrow functions inside CallExpressions. (https://github.com/palantir/tslint/blob/master/src/rules/typedefRule.ts#L83)
Did you really want to have to define the return type in every callback?

[nchen63]

@YuichiNukiyama: was it intentional to not warn on callbacks? I see one of the revisions in #1284 which disables the warning for the line @andy-hanson mentioned. If so, what was the thought behind that?

[YuichiNukiyama]

@nchen63
@andy-hanson is right. When defining arrow function in some method, outer method checks type of retern value. So, there is no point in checking the type.

[nchen63]

@YuichiNukiyama I thought that the point of the rule wasn't to declare types because they were necessary, but to do it to be explicit, as a matter of style

[cjbarth]

He is an example of where linting would be valuable. Currently, no linting error is generated:

let t: string[] = [
 "hi",
 "there"
];
let u: number[] = t.map((item: string) => { return item === "hi"; });

Having said that, it does appear that such a problem is picked up by the TypeScript compiler.

[JoshuaKGoldberg]

Sounds like the general thought is that the rule should be given an opt-in option to allow this behavior. Perhaps "child-arrow-call-signatures"? Any PR that adds the option should document why it isn't enabled by default (as per the above discussion).

[VincentLanglet]

I agree with @nchen63 ; this rule is not to declare types because they are necessary, but to document the code.

If you want to only declare type because they are necessary, use "noImplicitAny": true.

@JoshuaKGoldberg I don't think a child-arrow-call-signature is a good idea. If you look at the duplicate issue #227.

array.forEach(element => {}) does not complain
array.forEach((element) => {}) complains expected arrow-parameter to have a typedef.
array.sort((a,b) => {}) complains expected arrow-parameter to have a typedef.

Since array.forEach((element) => {}) return an error for arrow-parameter (without a child-arrow-parameter-signature option), for consistency, it should return an error for arrow-call-signature too.

Then array.forEach(() => {}) will return an error for arrow-call-signature.

Plus, array.forEach(function() {}) return an error, so there is no reason array.forEach(() => {}) does not.

[JoshuaKGoldberg]

This was fixed by #4533 🎉