💅 Unexpected removal of type with rule noInferrableTypes

[rubiesonthesky]

Environment information

CLI:
  Version:                      1.3.3
  Color support:                true

Platform:
  CPU Architecture:             aarch64
  OS:                           macos

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v20.9.0"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "npm/10.2.2"

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

Workspace:
  Open Documents:               0

Rule name

noInferrableTypes

Playground link

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

Expected result

: string should not be removed and the code should stay like it was.

function doSomething(param1: string = null) {}

Removing type form param1 will make its type to be any. If Typescript project would have strictNullChecks enabled, then this would not be a problem because there would be a type error with the existing code. But in project, where that is disabled, above code is valid.

Code of Conduct

• I agree to follow Biome's Code of Conduct

[ematipico]

Indeed, Biome shouldn't provide the suggestion, although this comes from code that even TypeScript doesn't like.

At the moment Biome can't understand the TypeScript configuration, so I'm not sure about what the rule should do in this case. Probably we should do more narrow checking of what's on the right of the assignment.

[rubiesonthesky]

Typescript is fine with the code with correct settings: Typescript playground

[rubiesonthesky]

I think, if the value is null or undefined, the rule should never remove the type unless the type is exactly same.

function doSomething(param1: null = null) {}

could be changed to

function doSomething(param1 = null) {}

But I think that in that case too, it would be better to left it alone.

Typescript Eslint does not complain about this with their similar rule. no-inferrable-types Typescript Eslint playground

[Conaclos]

Thanks for the reporting :)

[Conaclos]

At the moment Biome can't understand the TypeScript configuration, so I'm not sure about what the rule should do in this case. Probably we should do more narrow checking of what's on the right of the assignment.

Yes, I think we should assume that TypeScript is in the unsafe null mode.