@herrstucki Thank you for submitting this PR!

🔔 @johnnyreilly @bbenezech @pzavolinsky @digiguru @ericanderson @morcerf @tkrotoff @DovydasNavickas @onigoetz @theruther4d @guilhermehubner @JoshuaKGoldberg @jrakotoharisoa - please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead.

@herrstucki The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

The tests are failing because of how Typescript resolves JSX element constructors. When you changed SFC to return ReactNode, it made Typescript actually fail to resolve the type SFC to an SFC-type value-based component. To make it work you would need to change JSX.Element to be of type ReactNode instead of an interface extending ReactElement<any>

I'm not sure why it worked in the first place based on my understanding of the resolution rules for JSX constructors, because the current return type of SFC is ReactElement<any> | null and it is not assignable to ReactElement<any> but somehow it works.

Maybe one of the TS devs can help out or someone who knows more about the JSX rules in TS 😄

@herrstucki I haven't seen anything from you in a while and this PR currently has problems that prevent it from being merged. The PR will be closed tomorrow if there aren't new commits to fix the issues.

@ferdaber Thanks for the hint. When JSX.Element is React.ReactNode it works fine (see b36083e)! Although I'm not 100% sure if this is semantically correct 🤔

@herrstucki The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

Well, at least the react typings lint fine now but a lot of other packages seem to be broken by this 😥

Yes, the change to JSX.Element to ReactNode is a breaking change because before it used to provide access to key, props and type properties of the element itself for JSX expressions. The problem here is that JSX types are a black box, until React resolves what the element actually renders, it's just a plain object, so even though you (the implementer) knows that a certain component returns an array or null or whatever, what actually is being returned is a plain object until React resolves it.

I also can't think of a way this would work with the current JSX constructor rules that Typescript imposes... hmmmmmm 🤔

Ah, I didn't realize there was already an issue opened in the Typescript repo for this, see microsoft/TypeScript#21699

I don't think that until that is resolved you'd be able to change the return type to ReactNode safely, sorry.

Alright, I’ll close this then. Thanks for your feedback @ferdaber!