Add `import.meta.envName` for build EnvName

[maximepvrt]

Describe the feature

Describe the feature

The current implementation of envName in Nuxt allows for custom environment names (e.g., staging) to be defined at build time, as per the documentation https://nuxt.com/docs/api/commands/build#options & https://nuxt.com/docs/getting-started/configuration#environment-overrides. However, there is no straightforward way to access this custom envName at runtime.

Proposal: Introduce import.meta.envName to reflect the custom envName defined during the build process. By default, it would to return production, development, or test, but when a custom envName is provided, it would return the defined value (e.g., staging).

Use Cases:

1. Styling and Customization:

   if (import.meta.envName === 'staging') {
       setLogoColor('blue');
   }
   

2. Third-Party Module Configuration:

   import * as Sentry from '@sentry/browser';
   
   Sentry.init({
       dsn: 'https://[email protected]/12345',
       environment: import.meta.envName, // Pass environment, 'staging' for example
   });
   

Additional information

• [ ] Would you be willing to help implement this feature?

[maximepvrt]

linked to https://github.com/nuxt/nuxt/issues/30776

[maximepvrt]

@pi0 Is this feature planned to be included in Nitro v3?

[pi0]

@maximepvrt do you mind also raising a proposal for vite and linking it here? I like to know vite teams take on this as well at least.

[maximepvrt]

@pi0 With Vite it looks like this is already possible using modes: https://vite.dev/guide/env-and-mode.html#modes

[pi0]

Yes, but also different. In vite, it is import.meta.env.[MODE]: boolean while this proposal injects a static import.meta.envName: string which has good benefits and use-cases as you described above.

Ideally, it would be nice if this gets standardized (or at least discussed) within the Vite community before wider adoption here in Nitro, as we are trying to be as close as possible to Vite conventions.

[maximepvrt]

@pi0 It’s already mentioned in the documentation that import.meta.env.MODE returns the current mode name. Shouldn’t we use this notion of mode instead? It also allows having .env files specific to each mode.