defineConfig import.meta.dev
Hi Everybody!
I need to archive a (theoretically) easy thing.
In my defineConfig inside of app.config.ts, I need to resolve a variable based on if I'm running the server with bun run dev or with bun start.
The problem is that, I can't find the environment variable that tells if I'm running as DEV or as PROD.
In fact import.meta.env doesn't seem to be exporting a DEV or PROD variable.
Is there any way for archiving this?
Sharing the code down here
13 Replies
i believe the confusion is around the difference between application code (where all these non standard import meta stuff are configured to work) and setup code(where non of these makes sense because they're the one that set them up, most of the time this is the way it is)
process.env
is the right path but at this point you have to get in and handle them yourself with dotenv or similar, node --env-file
the most important thing is the actual environment which is usually the shell you're executing the command, there are multiple ways to set them up
here's one for most POSIX shells
e.g NODE_ENV=foo PORT=bar command
(theoretically) easybecause tool builders have to make it seem like it's easy for the sake of DX but it's nearly impossible to cover everywhere
Gm.
Thanks for your answer.
I actually didn't think about setting the ENV variable via CMD. And that's a great idea for archiving the desired result!
So, is this the only way for reaching my goal, in your opinion?
Thank you very much! :))
nah,
.env
also loads it lol
heck no, it only gets loaded on when the config gets saved
alright
here's another one
I had already set-up my env correctly.
console.logging(env) shown an interesting variable called npm_lifecycle_event that is start when npm start and dev when npm run dev.
I tried it out and it seems to work.
Do you think it's fine using this variable here rather than defining a custom one?
Probably not, it's likely added by
npm run
. You can also put the env in npm scripts.
for example
package.json
Perfect. Thanks! :))
(Just checked, yarn bun and npm have the npm_lifecycle_event variable btw)
Yeah, because https://docs.npmjs.com/cli/v10/using-npm/scripts#current-lifecycle-event
yarn bun etc probably emulate npm in terms of execution
Ok, so, my final approach will be something like this:
But, adding a custom env variable via CMD works perfectly fine either.
Thanks for the help ❤️
I wouldn't rely on it because
it'd be
hello
in this case
process.env.NODE_ENV
should be working but for some reason, it's not. This is a bug.
Ok, it seems to be a timing issue.
make vite a function that returns the object instead
then you can use process.env.NODE_ENV
This is very strange.
Sometimes it shows up, some other times it doesn't ://
Checking this right now
Yeah, it's buggy at the moment but on
build
it shows up with the correct value production
but vite
needs to be a function
vite seems to be working
feel free to file an issueTrue.
hot-refreshing it shows even development. But not starting it from scratch.
As you said, with the build command it shown production correctly
Posting down here my final configuration:
Thank you very much @mdynnl :))
Hey, so I just found that thread about env, and I wanted to ask something because I can't seem to find the anwser, yet this seems related.
I am loading env variables using a docker-compose file, populating the docker container via the
env_file:
instruction, and passing it my env file path. The container has the env variable loaded in it, but the app.config.ts
doesn't seem to find them. I don't want to load a .env file a this point, as it's already loaded through docker-compose. Neither import.meta.env
nor process.env
will expose the desired env variables. Even the ones prefixed by VITE_
(even though it's server side, so it should not matter, as far as I know).
Any clue of what could happen here ?
It looks like the env variable are not available during building process, as a console.log(process.env) won't reveal any shell env variable. I wonder how though ? How could I access them without having to load a .env file, but resolving the ones already available in the shell at build time ?