Inherit Vite modes behaviour via --mode CLI argument

[schibrikov]

Is your feature request related to a problem? Please describe.
I want to have different environments/modes like staging/production/testing and pass some environment-related variables to the application.

Describe the solution you'd like
Vite already provides such functionality through "modes" and accepts --mode argument in CLI. Depending on the mode different .env files may be loaded and their contents passes as import.meta.VITE_* variables.
I'd like Sveltekit to inherit this behaviour and pass --mode arg from CLI to Vite, instead of only limiting to development/production as it is now.

docs: https://vitejs.dev/guide/env-and-mode.html

Describe alternatives you've considered

• Setting the mode in Vite section of svelte.config.js using env variables
• SvelteKit could provide it's own mechanism for loading environment-related variables
• Manually replacing .env.production file during build step on CI

How important is this feature to you?

Due to having some workarounds I don't think it's critical, but it would be convinient to use CLI arg instead of ENV vars + reading them in config.

[jthegedus]

Until something like this gets adopted, the solution I have been using is:

# env.development - Vite.js defaults to "mode=development"
pnpm run dev

# env.staging
export MODE=staging && pnpm run build

# env.production - explicit override of svelte.config.js development default
export MODE=production && pnpm run build

// svelte.config.js
import firebaseAdapter from 'svelte-adapter-firebase';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	kit: {
		adapter: firebaseAdapter({ firebaseJson: '../firebase.json' }),
		target: '#svelte',
		vite: {
			// default to development as a guard
			mode: process.env.MODE || 'development',
		},
	},
};

[akvadrako]

You can also use NODE_ENV. When run with svelte-kit dev, process.env.NODE_ENV == 'development'.

[Rich-Harris]

I think the MODE=staging pnpm dev solution is preferable to adding new surface area to the CLI, personally. If you ever need more complex logic (varying other things based on the mode) it's much easier to do that in a config file based on an environment variable than something tucked away inside the framework.

In any case, 'only add new capabilities if they don't exist in userland' is a good general principle, so I'll close this issue.