Turn on no-explicit-any

[ShadowJonathan]

https://github.com/matrix-org/matrix-react-sdk/blob/010cbadc8ecf9f15ade94d87950734c873ca6095/.eslintrc.js#L81-L82;

            // We disable this while we're transitioning
            "@typescript-eslint/no-explicit-any": "off",

[turt2live]

It'd be good to have rationale for why this change is important to you.

[ShadowJonathan]

As I've explained in #2116, it is weird to me that some lints are disabled, as without them, breaking behaviour would be allowed that undermines the basis of TS' type-checking system.

any is an example of this, as it is TS saying "i don't know" in the sense that it does not properly understand a type-check inference that is taking place. Often these are types imported from outside libraries, but this can also include unknown data, such as JSON-parsed strings.

any propagates any, and it is not properly checked without lints such as #2120.

any is also assignable to anything, the following is allowed, and afaik, there are no lints forbidding it;

let a: any = {};
let b: number = a;
// now b is typed as a number without errors

There is an alternative, unknown, is is described as a "type-safe variant" of any, only being assignable to itself. Example, the following errors out;

let x: unknown = {};
let y: number = x;
// y errors with "unknown is not assignable to number"

So, with these alternatives, eradicating any from the codebase, and instead having every such instance (replaced by unknown) as dealing with truly unknowable data, could make code more safe and deterministic. Data returned from an API would have to be type-guarded (by checking properties and their types), or type-casted, before they're assignable to new types.

To me, this type of change seems obvious, as the alternative would be that behaviour surrounding any would be unchecked, it would break the basics of TS' type safety, creating a false sense of security, and leading to headaches, programmer bugs, runtime nullability problems, and at worst, vulnerabilities.