ImportMetaEnv's [key: string] should be unknown for type safety

[Samuel-Therrien-Beslogic]

Description

Using a custom env variable will by default be typed as any. To have the correct type, one has to use module augmentation. This is intended and working fine.

But even when you augment a value correctly, you are not protected against forgetting to add more, or mistyping the value.

/// <reference types="vite/client" />

interface ImportMetaEnv {
  readonly VITE_CORRECT: string;
}

import.meta.env.VITE_MISTYPED.at(1) // oops! Accepted by typescript! (some type-aware linters may warn)

Unfortunately, module augmentation doesn't seem to work since the index signature was already set ! So I can't simply opt-in to:

/// <reference types="vite/client" />

interface ImportMetaEnv {
  [key: string]: unknown
  readonly VITE_CORRECT: string;
}

import.meta.env.VITE_MISTYPED.at(1) // VITE_MISTYPED is still any :(

Hence, I am requesting for ImportMetaEnv to default to unknown, which is more accurate, more type-safe, and would promote adding used variables in ImportMetaEnv module augmentation.

Suggested solution

ImportMetaEnv should have [key: string]: unknown instead of [key: string]: any

Alternative

Using https://www.npmjs.com/package/patch-package to patch vite's source code on install.

Discover or request some way for module augmentation to override existing declarations.

Not include any index signature in ImportMetaEnv, and document that the dev should add one themselves based on the strictness they want.

Additional context

Relevant ongoing typescript conversations:

• Compiler option to switch lib .d.ts anys to unknown microsoft/TypeScript#60899
• Replace any by unknown in definition files microsoft/TypeScript#26188

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[bluwy]

related #19077

[Samuel-Therrien-Beslogic]

Hmm, a different approach but I think it would work as well.

My intuition tells me the conditional type should be done on any/unknown (any being the escape hatch), but I don't feel too strongly about it.

If that goes through, I'll have to ensure that my teams remember to use type ViteStrictImportMetaEnv = true