🐛 Biome CLI and VSCode extension disagree on noUnusedVariables

[MCFX2]

Environment information

CLI:
  Version:                      1.7.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:           "v20.12.0"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "yarn/4.1.1"

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

Workspace:
  Open Documents:               0

What happened?

1. Created a project using Vite
2. Edited vite-env.d.ts to define an ImportMeta (which is used for type-safe env configs)

interface ImportMetaEnv {
	// ... imagine there are fields here, contents not relevant
}

interface ImportMeta {
	readonly env: ImportMetaEnv;
}

3. Open file in VSCode, and additionally run biome check, and compare the results.
4. VSCode claims this is an error as the interface is unused, while biome check finds no issues.
   a. Also, this warning cannot be suppressed, because it hides the warning in VSCode but triggers a suppressions/unused warning on biome check.

Expected result

Either both will issue an incorrect noUnusedVariables warning, because the ImportMeta interface is not exported (and thus not used), or both will be fine with it. The actual fix in this case is to simply export the interface, but it's concerning that I would get a warning in one scenario but not the other.

Code of Conduct

• I agree to follow Biome's Code of Conduct

[Sec-ant]

I can reproduce this issue.

According to the TypeScript document:

Conversely, a file without any top-level import or export declarations is treated as a script whose contents are available in the global scope (and therefore to modules as well).

I think the correct behavior is to ignore any unused type declarations in such files because the moment they are defined, they can be accessed from the global in other files directly, or via /// <reference types="xxx" />.

To be more sepecific, type declarations should be ignored by this rule when:

• The file ends with .d.ts
• The file doesn't contain top-level imports or exports