feat: add import.meta.env support for environment variables

[xiaoxiaojx]

Summary

fixes #15833

What kind of change does this PR introduce?
feat: add import.meta.env support for environment variables

Did you add tests for your changes?
Yes

Does this PR introduce a breaking change?
No

If relevant, what needs to be documented once your changes are merged or what have you already documented?
TODO

[codspeed-hq]

CodSpeed Performance Report

Merging #19996 will degrade performances by 6.9%

_{Comparing xiaoxiaojx:metaEnv (d609f0e) with main (dd71426)¹}

Summary

❌ 1 regression
✅ 68 untouched

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	benchmark "three-long", scenario '{"name":"mode-development","mode":"development"}'	5.2 s	5.5 s	-6.9%

Footnotes

1. No successful run was found on main (c0c2bb3) during the generation of this report, so dd71426 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[alexander-akait]

Let's do couple improvement and think about updateOptions

[xiaoxiaojx]

I’m not sure if we really need an ImportMetaEnvPlugin. It seems sufficient to simply add import.meta.env.xxx keys for all process.env.xxx variables.
If we introduce ImportMetaEnvPlugin, it would replace every import.meta.env reference at build time — even those that don’t exist during the build but might exist at runtime.

[alexander-akait]

Hm, I think it is ok, we are doing the same with process.env... if you really want to store them dynamically (i.e. runtime available) you can use runtimeValue

[xiaoxiaojx]

Maybe all we need to do is just copy all the keys over to import.meta.env.

definitions[`process.env.${key}`] = defValue;
definitions[`import.meta.env.${key}`] = defValue;

The ImportMetaEnvPlugin would replace expressions like const env = import.meta.env; typeof import.meta.env; or import.meta.env.RUNTIME_VALUE at build time.
For example, process.env doesn’t support typeof process.env; or const env = process.env;

[alexander-akait]

Maybe all we need to do is just copy all the keys over to import.meta.env

Yeah, I think so, not sure we really need to support const env = import.meta.env and typeof import.meta.env... can you check other bundlers?

[xiaoxiaojx]

esbuild

[esbuild] import.meta.env:  undefined
[esbuild] typeof import.meta.env:  undefined
[esbuild] process.env.NODE_ENV:  development
[esbuild] typeof process.env.NODE_ENV:  string

Vite

[Vite] import.meta.env:  {BASE_URL: '/', DEV: true, MODE: 'development', PROD: false, SSR: false}
[Vite] typeof import.meta.env:  object
[Vite] process.env:  {NODE_ENV: 'development'}
[Vite] typeof process.env:  object

[alexander-akait]

Good question about import.meta.env, technically providing value will stop work runtime values, maybe we should do the same as with process.env, what do you think?

[xiaoxiaojx]

@alexander-akait Got it, let me refactor it.

[xiaoxiaojx]

Good question about import.meta.env, technically providing value will stop work runtime values, maybe we should do the same as with process.env, what do you think?

Yeah, I think the behavior of process.env is quite reasonable — let’s align with it.

[alexander-akait]

If someone ever opens a question about issue, we can always introduce a new option for this (on parser options level)

[xiaoxiaojx]

The refactor is now complete — the behavior of import.meta.env is aligned with process.env, as confirmed by the test snapshots. The PR is much smaller now, and any suggestions are very welcome!