Allow chosing different env files

[LucdoOf]

Hello,

I have a project in which i need to work with several env files, and none of them are simply called .env.

I usually chose my env file using the mode option of vite.

But, when you run a vite server using mode option on an existing env file without a default .env file the server crash with this error:

/var/www/Boreal/Upcover/Instances/Upcovel/node_modules/laravel-vite-plugin/dist/index.js:110
                        server.config.logger.info(`  ${picocolors_1.default.green('➜')}  ${picocolors_1.default.bold('APP_URL')}: ${picocolors_1.default.cyan(appUrl.replace(/:(\d+)/, (_, port) => `:${picocolors_1.default.bold(port)}`))}`);
                                                                                                                                                                     ^

TypeError: Cannot read properties of undefined (reading 'replace')
    at Timeout._onTimeout (/var/www/Boreal/Upcover/Instances/Upcovel/node_modules/laravel-vite-plugin/dist/index.js:110:166)
    at listOnTimeout (node:internal/timers:559:17)
    at processTimers (node:internal/timers:502:7)

In fact, in the configureServer method the env file loaded is the .env file, and it cannot be changed:

const appUrl = loadEnv('', envDir, 'APP_URL').APP_URL

I suggest to change this line to:

const appUrl = loadEnv(resolvedConfig.mode, envDir, 'APP_URL').APP_URL

And thus, add:

mode: mode,

In the config definition, it fixes the issue.

[jessarcher]

Was there a reason for this change? It seems to work fine without it.

[LucdoOf]

Oh really? Thought it wasn't defined at all. Maybe i went to quickly! Thanks for the quick review :)

[jessarcher]

If the user hasn't specified a mode (either via config or the -m flag) then it will be undefined in the UserConfig object at this point. Vite will automatically add the mode to the ResolvedConfig object that we access later, with a default of development, so there's no need for us to manually add it to the UserConfig, unless we needed to change it.

If you can remove this line, I'll get this merged in :)

[LucdoOf]

The thing is i don't want vite to parse ".env.development" but my own .env file. If i remove this line and no ".env.development" exists, the same error appears.
Even if i specify a mode using -m, without explicitly adding it to the ResolvedConfig it is set to 'development'.

[jessarcher]

Specifying mode: mode doesn't really do anything as far as I can tell. The ResolvedConfig object will have the same value with and without it being specified.

The default will always be development with or without it. If you specify a mode in your config or with -m, then the ResolvedConfig config should have that value, even without mode: mode.

If .env.development doesn't exist, that's okay. Vite looks for a few env files and merges the values together: https://github.com/vitejs/vite/blob/60721ac53a1bf326d1cac097f23642faede234ff/packages/vite/src/node/env.ts#L20-L25

Any files that don't exist are silently ignored.

The error you're seeing should only occur if none of the env files contains an APP_URL.

[LucdoOf]

Ok i understood the confusion.

I was using an npm script (npm run dev --mode=my_env_file) with the corresponding package.json:

"scripts": {
    "dev": "vite",
}

I don't know why, but when a mode is specified this way it doesn't appear in the resolvedConfig object.

Running vite with vite --mode=my_env_file work tho.

I'll just remove the mode:mode line, sorry for this !

[jessarcher]

I don't think npm run <script> passes arguments or options through to the underlying command, so your -m flag would be ignored.

If you run npm run dev -- -m mode then it should pass everything after the -- through.

[LucdoOf]

Thing is it get passed here correctly, even with the npm version:

config: (userConfig, { command, mode }) => {

That's why i'm finding it kinda strange but its ok i'll deal with it :)

[jessarcher]

That is strange! When I run npm run dev -m test, the mode is passed into this function as development.

[LucdoOf]

Oh. Strange lol. Let's forget about this haha

[jessarcher]

This makes sense. Not sure why I didn't do this originally, but I've given it a test using npx vite -m example and it works well 👍

[jessarcher]

Looks good! Thanks for the contribution!