Open to feedback on the name here.

This is technically the relevant RHS type ofJSXAttribute, so this check could also recurse one level higher if that is preferred. This should be the only way to directly supply a function in JSX though.

I think we'll want to check the parent because this is another valid location for aJSXExpressionContainer:

<>{()=>{}}</>

@bradzacher Ah, I totally forgot about the render-props pattern, it's been a while since their heyday! Running this down actually led me across an existing issue in TS where fragment shorthands are not typed properly:microsoft/TypeScript#50429

I went around on this for a while, but I again think allJSXExpressionContainer instances are fully bound by types barring that issue (reference CodeSandbox with render props):

1. Attribute assignment: original case; type is constrained by assignment
2. Render props of built-ins and<Fragment />: not allowed due to limited child types (JSX.ElementType orJSX.Element | null); all functions will be type errors here
3. Render props of<> fragment shorthand: all functionsshould be type errors here
4. Render props of components with custom function children: properly typed-constrained by explicitchildren prop, the same as if children was defined via attribute

I eventually realized that while something like this is unsafe:

<>{()=>'bug'}</>

Having a lint error that turns it into this doesn't make things better as it's still not a type error but won't work as expected at runtime (especially if you return an object instead):

<>{():string=>'bug'}</>

While this is a currently an issue with TypeScript, it doesn't seem like the lint rule can do anything better here in place of proper type-checking. But functions can be valid in children expression containers generally.

Reference TS-ESLint playground

DRYing these out, it makes it more obvious that the recursive object-property case doesn't include thisisConstructorArgument() case, but it seems like it should?

Happy to move it intoisTypedParent() and add tests if this is indeed a bug.

I think we'll want to check the parent because this is another valid location for aJSXExpressionContainer:

<>{()=>{}}</>

for completeness can we also get this as aninvalid test?

Added negated counterparts of all new tests