Handling server-side/sensitive/runtime variables

[GrygrFlzr]

Context

Currently, Vite indiscriminately replaces process.env. with ({}).:

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

Lines 33 to 38 in 7cd8d78

	const replacements: Record<string, string | undefined> = {
	'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV || config.mode),
	...userDefine,
	...importMetaKeys,
	'process.env.': `({}).`
	}

I'm not sure if this behavior is Vite is attempting to protect SPA authors from accidentally using process.env.SECRET in their code. Confirmed with Evan that this was to support libraries that indiscriminately use process.env.NODE_ENV.

The Problem

Applications that have a server-side encounter a common issue of needing to be able to access sensitive information from environment variables, e.g. database or API credentials. Aside from secrets, it is also possible to require runtime variables that you don't know at build time. Currently people are working around this using process.env['SECRET'] to avoid the string replacement, but it is entirely possible that in the future Vite decides to similarly replace process.env[ with ({})[ given the above code. I am unsure if this is the "blessed" way to access secrets or an oversight, considering it completely circumvents the concerns written above.

Using VITE_ prefixed environment variables is not a solution. It is explicitly documented that it should not contain sensitive information.

Using define is not a solution:

• That would be baked in at build time, which is not appropriate for all use cases.
  (e.g. heroku database URLs can change across application reboots, so runtime ENV vars are required)
• That exposes it to client side code because it blindly does a find-and-replace.

Potential Solutions

(in no particular order)

• This could instead be implemented individually by SSR providers. This seems counterproductive if the solution can be framework-agnostic, but would be a necessity if it is determined to be outside of Vite's scope or capabilities.
• Declare process.env['SECRET'] as a "blessed" way to access runtime variables, although then it is unclear why process.env. is replaced in the first place.
• Stop replacing process.env. - This replacement behavior is not currently written in the docs.
• Create a "store" somewhere (in the Vite config?) that could contain such information, although I'm not sure how to expose this to the user. Vite doesn't really "know" about server vs client code aside from SSR'd code, and not all SSR code should have access to secrets. This also doesn't really solve the runtime non-secret situation.
• Have a config option to disable the process.env. replacement.

Non-solutions

• Start replacing process.env[ with ({})[ if you're sadistic

[Conduitry]

It seems to me that, at best, what the current ({}). behavior achieves is hiding problems from people who end up with process.env. in code that's destined for the browser. ({}).FOO doesn't seem like it would result in correct behavior in any case, other than just that it wouldn't crash like process.env.FOO in the browser would. I would argue though that crashing is better than quietly providing unexpected behavior.

If removing this replacement isn't a viable option for compatibility reasons, then I think this should be configurable in some way - if not in all cases, then at least in SSR situations, where there is a legitimate reason to be using process.env..

[b-fuze]

Why not replace it with optional chaining and globalThis? e.g. process.env. becomes

(globalThis.process?.env ?? {}).

And ofc, making this configurable is another option

[arxpoetica]

Been futzing around with process.env.* all evening, and I can't understand why Vite doesn't make server-side process.env.* a first-class consideration.

The current lack of solutions is highly frustrating.

[hatemjaber]

Until there's a solution for this, is safe to import dotenv in the hooks file and use process.env['WHATEVER'] in server side code? I tried to access those variables in svelte files and it seems that vite does ignore them by default; I'm assuming it's safe and the only workaround at the moment.