Expose environment variables also on import.meta.env

[Tobbe]

For compatability with webpack, and for consistency with node/server environment we want to support reading env vars from process.env. But we also want to support Vite's way of doing it, which is exposing them on import.meta.env.

And this is a copy/paste from the code

// Vite can automatically expose environment variables, but we
// disable that in `buildFeServer.ts` by setting `envFile: false`
// because we want to use our own logic for loading .env,
// .env.defaults, etc
// The two object spreads below will expose all environment
// variables listed in redwood.toml and all environment variables
// prefixed with REDWOOD_ENV_

Note: This does not work for Vite's html %% replacement because of vitejs/vite#13424
But we've got a separate PR that takes care of that in #8929

[jtoar]

Working locally for me. @Tobbe it doesn't see like we need the EnvironmentPlugin at all now with these changes, so I'd say we get rid of that just so we don't have duplicate code:

redwood/packages/vite/src/index.ts

Lines 223 to 236 in 3b548f2

	// Loading Environment Variables, to process.env in the browser
	// This maintains compatibility with Webpack. We can choose to switch to import.meta.env at a later stage
	EnvironmentPlugin('all', { prefix: 'REDWOOD_ENV_', loadEnvFiles: false }),
	EnvironmentPlugin(
	Object.fromEntries(
	rwConfig.web.includeEnvironmentVariables.map((envName) => [
	envName,
	JSON.stringify(process.env[envName]),
	])
	),
	{
	loadEnvFiles: false, // to prevent vite from loading .env files
	}
	),

Otherwise looks good to me!

[Tobbe]

Moved this plugin up here because it has order: 'pre' which will make it run firsts. So intuitively it makes sense to me to have it first in the array of plugins. The reason it was further down before was because we wanted to group it with the other env-related plugin. But now that we removed that one that argument doesn't hold true anymore