Consider using strict TypeScript option

[Kukkimonsuta]

Consider whether enabling strict option in tsconfig would be possible. Given the size of the codebase it is enormous effort, however long term it provides great benefits. Strict option enables bunch of additional checks which aren't enabled by default because of backwards compatibility, but the option is recommended to be set to true.

strictNullChecks
One of the most important checks nowdays is strictNullChecks, especially for libraries because it propagates to consumers code through typings. If I want to use useControlled hook in my codebase with strictNullChecks enabled I get following errors:

This check also forces developers think about null and undefined values at all times. It can be annoying at first, but from my experience it avoids a lot of bugs and gives clear intent on whether property/parameter/variable is supposed to be able to contain null or undefined values or not.

noImplicitAny
Other checks enabled by strict are good to have as well, for instance noImplicitAny which currently caches a lot of any uses - some of which seem to be only thanks to TS not being able to look too far into generics like here

which I don't think we can realistically handle properly, but it's still nice to be alerted and knowingly work around it.

[rtivital]

I use strict option in some of my other projects and cannot say that it brings much value in any of them. All it does is forcing me to add null to my types, e.g. in your example it will be string | null (which will fix the error btw), maybe this is an unpopular opinion but I always consider null as a valid empty value and prefer to use type instead of type | null as code becomes much more readable for me.

noImplicitAny is fine but won't work because of components that support component prop (as in your examples) – types are there but are not propagated to component because of ComponentPassThought bug – if you can find and fix the issue with this that would be great, but it does not bother me too much since this is not affecting public API in any way and used mostly in simple components.

[Kukkimonsuta]

All it does is forcing me to add null to my types, e.g. in your example it will be string | null (which will fix the error btw)

I disagree that's all it does - the main point is to force you to think about nulls and undefineds. That said you do have pretty good coverage of correctly handling nulls/undefineds in the codebase. For us however it's imperative we have strict enabled, so would you be ok with PRs adding | null annotations to public API wherever I encounter the need so people with strictNullChecks enabled can use this properly without hacks like value: null!,?

[rtivital]

Yep sure, making this for public APIs is fine