Should add process.env.NODE_ENV to client types.

Vite types should define process.env.NODE_ENV

process.env.NODE_ENV should be defined by vite references since it’s inherently relevant.

I know I can easily import it myself, or add it to tsconfig. That being said I like to keep keep my global namespaces unpolluted so I tend to go with explicit imports as much as I can. Like

"typeRoots": [],
"types": [],

Statically replacing NODE_ENV at compile time is one of the main ways to eliminate dead code since it’s easier to compare "production" === "production" than variable === "production". And since Vite is a build tool, it should supplement the type.

Suggested solution

Something like

declare namespace NodeJS {
  export interface ProcessEnv {
    NODE_ENV: string 
  }
}

inside /// <reference path="./types/importMeta.d.ts" />

Alternative

Could use tsconfig or declaration merge in a local file.d.ts to do it myself, but I actually find it comforting that vite gives me everything relevant to build tools out of the box.

I got a BuildTimeTypes.d.ts files with

/// <reference types="vite/client" />
/// <reference path="./types/importMeta.d.ts" />
/// <reference types="vitest/importMeta" />

interface ImportMetaEnv { 
  readonly RUNTIME_VERSION: string
  readonly RUNTIME_REACT_VERSION: string
  readonly RUNTIME_BUILD_SHA: string
  readonly RUNTIME_BRANCH: string
  readonly RUNTIME_BUILD_DATE: string
  readonly RUNTIME_CONFIG_ASSETS_LIMIT: string

}

Seems like it would be perfect inside "./types/importMeta.d.ts"

Additional context

I don’t mind doing the PR.

No response

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.

[seivan]

That’s beyond the point. Vite is using process.env.NODE_ENV internally. React is using it. Every single library you got… is using it.

You can make the claim that import.meta.env will eventually replace it, but that is not your case today. Not to mention it’s nice having ONE standard used for shaking dead code off.

I use import.meta.env to assign for runtime conditions, but for anything that that’s absolute I will be using process.env.NODE_ENV, because it’s transparent and tangible. I can set it myself without worrying about the conditions the build system does to decide wether or not we’re “dev” or “prod”, and I can expect the dependencies used to do the same.

[bluwy]

process.env.NODE_ENV is a standard in nodejs only. There’s no process in the browser, hence Vite introduce import.meta.env for it. It’s common for libraries to use them, even if they are for browser usage, but that was because exports didn’t exist then (production and development conditions are preferred now). But for project source code that’s written for browsers, it should be avoided.