💅 Evolving any is considered implicit any by noImplicitAnyLet

[bgenia]

Environment information

CLI:
  Version:                      1.5.3
  Color support:                true

Platform:
  CPU Architecture:             x86_64
  OS:                           linux

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v21.5.0"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "npm/10.4.0"

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           true
  Linter disabled:              false
  Organize imports disabled:    false
  VCS disabled:                 true

Workspace:
  Open Documents:               0

Rule name

lint/suspicious/noImplicitAnyLet

Playground link

https://biomejs.dev/playground/?code=LwAvACAARQB2AG8AbAB2AGkAbgBnACAAYQBuAHkAIABpAHMAIABjAG8AbgBzAGkAZABlAHIAZQBkACAAaQBtAHAAbABpAGMAaQB0ACAAYQBuAHkACgBsAGUAdAAgAGIACgBiACAAPQAgADEACgAKAC8ALwAgAEUAdgBvAGwAdgBpAG4AZwAgAGEAcgByAGEAeQAgAGkAcwAgAGkAZwBuAG8AcgBlAGQACgBjAG8AbgBzAHQAIABhAHIAcgAgAD0AIABbAF0ACgBhAHIAcgAuAHAAdQBzAGgAKAAxACkACgBhAHIAcgAuAHAAdQBzAGgAKAAiAGgAZQBsAGwAbwAiACkACgA%3D

Expected result

Evolving any

let b
b = 1

This case should be only marked as "implicit any" if noImplicitAny tsconfig option is set to false. If the purpose of this rule is specifically to forbid using evolving any I suggest at least changing the rationale in the docs because currently it does not make sense.

The docs say that this is a "dangerous escape hatch" and typescript's noImplicitAny doesn't report this case, this is because it's not actually an any. This is a separate feature which allows inferring variable type from assignments. This is type safe.

Example 1
Example 2

See microsoft/TypeScript#11263 microsoft/TypeScript#45369 microsoft/TypeScript#54414

Evolving arrays

This behavior also exists in a form of evolving arrays, for which biome does not check.

const arr = []
arr.push(1)
arr.push("hello")

Example 1
Example 2

If this rule is meant to ban evolving types, I suggest banning this too.

See microsoft/TypeScript#11432 microsoft/TypeScript#43752

Code of Conduct

• I agree to follow Biome's Code of Conduct

[Conaclos]

Good point. We should certainly rename the rule and add more cases.

[bgenia]

Another case of control flow inference for which biome does not check:

class Example {
       b
    // ^? inferred as number

    constructor() {
        this.b = 2
    }
}

Playground
Example 1
Example 2

This is practically the same case as implicitAnyLet

[fujiyamaorange]

@Conaclos
May I try this issue?

[Conaclos]

@fujiyamaorange
Which changes would you like to introduce? It is not clear to me for now...

[fujiyamaorange]

I plan to redefine this case as valid because it seems a kind of evolving any type according to @bgenia .

let someVar1;
someVar1 = '123';

I also referred this article.

[Conaclos]

I plan to redefine this case as valid because it seems a kind of evolving any type

This could make the rule useless?

Instead, I could create a new rule noEvolvingAny and I could deprecate noImplicitAny (once noEvolvingAny is stabilized).
The new rule could report these cases:

let a; // the current `noImplicitAny`
const b = [];
let c = null;

If you would like to work on this new rule, you are welcomed :)

[fujiyamaorange]

Oh, fantastic!
Thank you for explaining me about the problem. I understand.

Let me try this!

[fujiyamaorange]

@Conaclos
Could you please assign me ?? 🙏

[unvalley]

We have noEvolvingAny lint rule now, so I close this issue.