Vite doesn't load environment variables for the specified mode

[barren horizon]

I am using turborepo for my monorepo. In there are a sveltekit app, a chrome extension and some shared types.

This is the dev task of my turbo.json:

    "dev": {
      "cache": false,
      "persistent": true,
      "dotEnv": [".env.local", ".env.staging", ".env"]
    },

These are the contents of my env files:
.env

VITE_TEST=123

.env.staging

VITE_TEST=12345

I am trying to set up different modes for the sveltekit app.
To test this, I temporarly changed the dev script of it to this:

 "dev": "vite dev --mode staging",

Logging import.meta.env gives me this result:

{
  VITE_TEST: '123',
   BASE_URL: '/',
   MODE: 'staging',
   DEV: true,
   PROD: false,
   SSR: true
 }

why didn't the VITE_TEST of .env.staging load?

[barren horizon]

bump

[gleaming wolf]

i suspect it has something to do with turborepo and not vite

i wasn't able to reproduce the behavior with a vite only setup

huh, it works fine on my end ... even with turborepo

are you able to send the minimal reproduction of your repo?

https://github.com/vercel/turbo/tree/main/examples/with-vite using this template

[barren horizon]

I was able to fix it by changing my dev command in the root package.json from

"app:dev": "dotenv -- turbo dev --filter @podsuite/app",

to

"app:dev": "dotenv -e .env.desiredEnvFile -- turbo dev --filter @podsuite/app",

this way, import.meta.env returns the correct env variables

Sorry about the confusing naming on the latter, this was just for testing purposes.

I am not 100% sure what this is doing but I assume this way I override all defaults by explicitly loading the .env.desiredEnvFile file

I haven't tested it in production tho

[barren horizon]

This is the documentation I found for it: https://turbo.build/repo/docs/handbook/environment-variables#advanced-configuration-per-workspace-environment-variables

Please let me know if thats wrong, I have no idea what I am doing 🥲

Ok so it seems like its not working in production

Im gonna try to reproduce it with the repo you sent me

[gleaming wolf]

ok, good luck

[gleaming wolf]

feels weird that you have to use dotenv there

[barren horizon]

I was able to reproduce it: https://github.com/Wizzel1/my-turborepo

So i commited both .env files and updated the scripts and tasks.

Run pnpm web:dev or pnpm web:staging from the root to change modes

[gleaming wolf]

hi @barren horizon sorry for the late reply

i saw your repo, and some things i did differently is that:

• i didn't use dotenv-cli and relied on vite to pipe the corrent environment variables
• i put the .env files in their respective app directory, so for example if i wanted to load an env for apps/web then i'd put the .env and .env.staging there instead of in the root (this is done since the root is managed by turbo instead of vite)

https://github.com/FreeJ1nG/turbo-vite-test-env

here is my repo if you were wondering

[barren horizon]

No worries. So what if I wanted to use the same .env for multiple projects?

I would need to do it with turbo then?

[gleaming wolf]

true, yea it looks like my way of doing it doesn't account for your particular use case

https://www.npmjs.com/package/dotenv-cli

i had a read on the docs, it looks like you can pass a -c flag to specify what .env.[type] you want to apply

did you maybe try that?

[barren horizon]

Not yet but I’ll give it a read.

The -e flag also worked as described here: https://turbo.build/repo/docs/handbook/environment-variables#advanced-configuration-per-workspace-environment-variables

I will need to check what the difference is

Also the production version now works for me. (I just forgot to create the variables in vercel)

[gleaming wolf]

wait so is it fully working like you expect now?

[gleaming wolf]

ahhh nvm then, pretty sure the -c behaves more like a matcher, where if you declare -c staging then it'd look for .env.staging, .env.staging.local

-e is probably what ur looking for in that case, but i didn't really see it in ur gh repo

[barren horizon]

Maybe I should just do it the way you are doing it. By placing the .env files in the apps

[gleaming wolf]

but if you do have some shared config, i feel like there must be a better way

and if turbo recommends dotenv-cli, i'm sure that's the right way to go

i've not worked with turbo before, so not quite sure about it 🫠

[barren horizon]

It seems like that

[gleaming wolf]

then why change it if it's currently working?

[barren horizon]

I don't have enough experience to know if this will bite me in the ass in the future

Security or functionality wise

So I was wondering if this is the right way

[gleaming wolf]

if that's the case, you should probably go over to the turbo discord and ask there

but in my opinion, if you need to have a shared config then you should probably have a .env.global in the root

and have the rest in each of the individual repos, be it for overriding the global env, or adding new app-specific env variables

[barren horizon]

I will do that. Thank you so much for your help!