Rule proposal: Disallow implicit casts from/to any

[emlai]

In my experience a frequent source of errors in TypeScript is implicit conversion from/to any.

noImplicitAny and no-explicit-any do help, but sometimes third-party libraries return e.g. any[] that still needs to be cast. For example:

  const result = await database.query('SELECT * FROM foo')
  doSomethingWith(result.rows) // result.rows has type `any[]`

I propose to add a rule that flags the above implicit conversion from result.rows to whatever doSomethingWith parameter type is, and requires the user to cast it explicitly:

  doSomethingWith(result.rows as Foo[])

Now if the doSomethingWith parameter type changes, result.rows is not silently cast to a possibly wrong type.

[bradzacher]

I'm not sure how much value this has, at least from your example.
IMO this creates a "brittle" state in your code where you'll have to manually update an (unnecessary) typecast if the function signature ever changes.

If you've got some more examples to help justify it, I'd love to see them.

---

Just as a side note:

If you have control of the typings for the function (doubt you do, but as an FYI anyways), you can accomplish this with the unknown type:

declare var database: {
    query(q: string): {
        rows: unknown[],
    },
}

type Foo = string;
function doSomethingWith(rows: Foo[]) {}

const result = database.query('SELECT * FROM foo');
doSomethingWith(result.rows); /*
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
Argument of type 'unknown[]' is not assignable to parameter of type 'string[]'.
  Type 'unknown' is not assignable to type 'string'.
*/
doSomethingWith(result.rows as string[]); // no error

repl

[emlai]

IMO this creates a "brittle" state in your code where you'll have to manually update an (unnecessary) typecast if the function signature ever changes.

I think you specifically do want to manually check the call site if the function signature changes, because result.rows might no longer have the correct type for the function.

Yeah if you control the typings you can just use unknown instead of any everywhere. This rule would give you the benefits of unknown when using third-party libraries that still use any.

[ThomasdenH]

Do you mean the no-unsafe-any rule?

[ThomasdenH]

The unknown keyword is always preferred in a strict codebase. However, since many libraries do not yet use unknown for various reasons, the rule is essential for a statically checked project.

For example, the signature for JSON.parse should look like this: (in: string) => unknown. Instead, it looks like this: (in: string): any. This means that the following crashing code is allowed by Typescript:

let a: { property: { subproperty: string } };
a = JSON.parse("{}");
console.log(a.property.subproperty);

Playground

The proposal to add this option in Typescript was closed, as the unknown type fixes this eventually, and the no-unsafe-any lint covers the other cases.

[mohsen1]

The TypeScript team decided this is not useful as a strict flag. But I support this as an ESLint rule

[emlai]

no-unsafe-any seems to allow implicit conversions from any[] to T[]. I would like the lint rule to also catch those.

[ThomasdenH]

And preferably there would be a better error message that gives a hint about what coercion is happening.

[bradzacher]

I've written up a more detailed proposal #306 which covers more cases.
I'm closing this in favour of that.

[bradenhs]

I've written up a more detailed proposal #306 which covers more cases.
I'm closing this in favour of that.

#306 is this issue

[bradzacher]

#306 is this issue

I meant - #791