💅 False positive noUselessConstructor for changed data modifiers

[vbudovski]

Environment information

CLI:
  Version:                      1.4.1
  Color support:                true

Platform:
  CPU Architecture:             x86_64
  OS:                           macos

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v20.10.0"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "pnpm/8.11.0"

Biome Configuration:
  Status:                       unset

Workspace:
  Open Documents:               0

Rule name

noUselessConstructor

Playground link

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

Expected result

The rule should not be triggered in this situation. See TypeScript playground link below for error resulting from suggested linter fix.
https://www.typescriptlang.org/play?#code/MYGwhgzhAEBCkFNoG8BQ1oAcBOBLAbmAC5LYJgAmA9gHYgCe0hIAXNBEXjQOYDc60ATiolgJCtGC0O2AK5iq2ABTM2M3DwCUKARiIALXBAB0zaAF4mYEPwwBfVA9ShIMACIIIwBDQpgaRNAIAB4kvjDwEEhoAPQxGJLSnPJEiirWapwa3Nqx8QnsspgIysyaqHEJDk5SNBzQEpY0CADu0B5ePn4BSgDk+gggIFQAhL3lQA

Code of Conduct

• I agree to follow Biome's Code of Conduct

[Conaclos]

Thanks for bringing this to light!

We currently have no way of retrieving the accessibility modifier of the parent's constructor. The only way to fix this is ignoring claases that extend a class. However I see a possible workaround: we could ignore the constructors with an explicit public accessibility modifier. TypeScript Eslint has the same issue and seems to allow this workaround (not sure that this was intentional).

TypeScript ESLint documented the caveat and decided to not fix this rare false positive.

Any opinion?

[vbudovski]

I can’t say I agree with the TypeScript ESLint reasoning. The reason for using TypeScript is precisely to take advantage of as much typing as possible. I don’t particularly like the explicit public specifier as a workaround, as it could cause confusion if removed. I’ve disabled the lint rule on the problematic line for now.

How difficult would it be to get access to inheritance chain?

[Conaclos]

How difficult would it be to get access to inheritance chain?

If the class is in the same file, it isp ossible. Otherwise, the infrastructure is currently uable to query other files. This requires to change the underlying infrastructure. By the way it si something we plan to do to support multi-file analysis.

[vbudovski]

It’s not a huge issue for the moment. Better to wait for the proper fix with the planned multi-file analysis. Worth documenting the edge case for now. Thanks for investigating!

[Conaclos]

Definitively! We should document this.

[ematipico]

This has been documented