feat: preserve process env vars in lib build

[bluwy]

Description

Fix #3229

Preserve process.env.* in library mode build

Additional context

I also found a bug where process.env.UNKNOWN isn't replaced as ({}).UNKNOWN in non-lib build mode. Bug introduced in #5972. Seems tricky to fix but otherwise I'll open an issue soon.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[bluwy]

Tests are fixed. Seems like CI is flaky though

[patak-dev]

Tests are fixed. Seems like CI is flaky though

It is killing us, there is a node seg fault we are hitting constantly in v16

[latk]

For anyone else who stumbles over this backwards-incompatible change in Vite 3.0: to get back env var replacements in lib builds, it is now necessary to manually add the relevant definitions to the Vite config. For example:

export default defineConfig({
  define: {
    "process.env.NODE_ENV": JSON.stringify(process.env.NODE_ENV),
  },
  ...
}

This will allow the resulting libraries to be used directly in the browser, without needing an additional build step.

[bluwy]

Thanks for the tip @latk. I think this is worth a mention in the docs, since specifically mentions building a browser-oriented library. I'll make a PR for it.

[gwsbhqt]

@bluwy bluwy, I have a question, why skip the library build pattern case?

vite/packages/vite/src/node/plugins/define.ts

Lines 15 to 30 in 1128b4d

	// ignore replace process.env in lib build
	const processEnv: Record<string, string> = {}
	const processNodeEnv: Record<string, string> = {}
	if (!isBuildLib) {
	const nodeEnv = process.env.NODE_ENV || config.mode
	Object.assign(processEnv, {
	'process.env.': `({}).`,
	'global.process.env.': `({}).`,
	'globalThis.process.env.': `({}).`
	})
	Object.assign(processNodeEnv, {
	'process.env.NODE_ENV': JSON.stringify(nodeEnv),
	'global.process.env.NODE_ENV': JSON.stringify(nodeEnv),
	'globalThis.process.env.NODE_ENV': JSON.stringify(nodeEnv),
	__vite_process_env_NODE_ENV: JSON.stringify(nodeEnv)
	})

I am using react to build a library for the browser. React used process.env.NODE _ENV, and I found that you skipped the library mode when dealing with process polyfill. Is there any special reason for this?

Of course @latk 's method can solve my problem, I'm just curious.

[bluwy]

@gwsbhqt Do you mean the process.env. polyfill being skipped specifically? It was so that nodejs libraries built with library mode can access process.env.* too, otherwise there isn't a way around it.

[smeng9]

Hi @bluwy The behavior of code in define.ts when handling import.meta.env replacement in lib mode does not match the comments here https://github.com/vitejs/vite/blob/main/packages/vite/src/node/plugins/define.ts#L40

Shall we introduce a config flag replaceImportMetaEnv to the https://vitejs.dev/config/build-options.html config section and let user decide whether to replace or preserve?

[bluwy]

Hmm that comment should be removed. It's likely I was testing things out and copy-pasted wrongly. The reason is that import.meta.env is a Vite specific feature, and we don't want libraries that work in Vite only. If you'd like, you can send a PR to remove that line.