accessing env on client
I've put const variable to shared folder to read env. When importing it from @wasp/shared on server side it works fine but with client I'm getting in browser. So, how to read env on client?
25 Replies
I get it working with
import.meta.env
But only with REACT_APP prefix and placed in .env.server 🤔Thanks, it worked.
I think docs should tell something about this, @Wasp Team ?
yeah but I think it should be fixed 😅
like client is usually expected to be prefixed with VITE, since it's vite now
and load from .client, or live all in one .env file
Yep we have an issue for the env variables prefix
We should update the docs as well 🙂
@miho it is this issue I believe? https://github.com/wasp-lang/wasp/issues/1036 .
It covers having unified prefix I believe. What about the
import.meta.env thing in Vite vs process in node, what can we do about that, can we modify it to be same on both sides, or do we just warn about it in docs? Do we have an issue for that -> should we open a new one or add it to existing one?Any news on this?
@Gwaggli Hey, this is in our pipeline and will be something we will handle in the next month most likely. Do you have some specific issues / problem with this / are you blocked with sometihng?
Hi @martinsos Thanks for the reply 🙂 i cant manage to get the env variables to work in the client side in production. When I do it like Fecony suggested by adding the variable to the backend and importing it with
import,meta.env it works locally but not once deployed to fly.io@Gwaggli Hm, if it is available during development but not during production, that means the way you used it in development is probably not completely right.
Specifically for the client side, the place where env vars are "applied" is when the project is being built (so during running
npm build inside of the client dir that was generated via wasp build, which you will usually do before deploying).
Can you tell me where you defined this env var?@martinsos I've added it to the
.env.server file with the mentioned REACT_APP_-Prefix. And then used it in the client with import.meta.env which worked fine while developing (using wasp start) but when i deploy it (using wasp deploy fly deploy i would kind of expect to add those variables to the fly secrets via the flyctl or the web ui, no? Or how would i use different env variables depending on the environment (local, test, prod)?Wohooo @Gwaggli, you just became a Waspeteer level 2!
hey hey, having the same issue but slightly different @Wasp Team. All my variables in env.server are prefixed with REACTAPP (besides SEND_EMAILS_IN_DEVELOPMENT, MAILGUN_API_KEY, MAILGUN_DOMAIN) and when I import.meta.env; client-side the issue I get is: The 'import.meta' meta-property is only allowed when the '--module' option is 'es2020', 'es2022', 'esnext', 'system', 'node12', or 'nodenext'.
@jtawf I managed to fix this by adding the module property to the tsconfig inside the client directory
There is a
.env.client for setting up client variables https://wasp-lang.dev/docs/language/features#envSo
.env.server is here to be used only for the server side of your app, and only during development.
Same goes for .env.client.
I am actually surprised that you @Gwaggli managed to access those variables in your client code if they were defined in .env.server, that shouldn't be happening!
As I said, .env.client also doesn't go beyond development, so those variables will not be applied during deployment.
So how are env vars to be set for the production / deployment, if .env.server and .env.client are not useful there?
For server, you set them via whatever mechanism your hosting provider gives: for fly, if using wasp deploy fly, check the docs here https://wasp-lang.dev/docs/deploying#setting-secrets .
For client, I am not 100% sure at the moment, I would have to check it out, but I believe you can prepend REACT_APP_SOMENAME=SOMEVALUE to the front of the command you are using to build the client -> so you would for example do REACT_APP_MYVAR="myvalue" wasp deploy fly deploy --skip-server.
I am curious though, why are you setting the client side env vars? Those are not so commonly needed -> what is your use case?Deploying | Wasp
Wasp is in beta, so keep in mind there might be some kinks / bugs, and possibly a bit bigger changes in the future.
Yeah i also thought its weird. But i just tested it locally and defined the same variable in both env files with different values and i get the same value both on the client and the server side: the one from the
.env.server.. If i only define it in the .env.client i get undefined when i try to use it with import.meta.REACT_APP_MY_VAR. Setting the backend env variables works with fly by setting them via the web ui.
I am deploying the app to different servers to have multiple stages (test and prod) and I do print some URLs in UI which should be dependent on the environment so I would like to include the base URL for those in the .env file. Also, I need to allow some features only in the test environment.@Gwaggli ok, that makes sense! I opene a bug report for the .env.server vs .env.client behaviour, we will investigate that. Also opened another issue to improve our docs on the whole matter, they are certainly lacking at the moment!
As for solving your problem right now, I believe the thing I mentioned above with prefixing the
wasp deploy fly command with env vars should help. The thing is, these vars are "baked" into the client at the moment it is being built, which happens on your machine, not later on Fly, so setting them up there doesn't do anything, which is why they need to be provided while building it.
What we could do in the future is allow a nicer way to load those -> maybe via another .env file, that would provided to the wasp deploy fly command.@martinsos Thank you very much! let me know if I can be of any help 🙂
For my understanding: the server envs are loaded from the fly secrets, but not the client ones?
Exactly, so server reads those from the fly machine it is running on, specifically from the fly secrets set for that machine.
But, client doesn't -> clien't obtains its secrets only once, during build time (which happens when you run
wasp deploy fly deploy ...), which happens on your machine. Once it is deployed to fly machine, it doesn't care about the secrets up there, it already comes with baked in env vars.Alright makes sense.
So when i want env variables on the client side, i define them when building the client (
wasp start, wasp build or wasp deploy) by prefixing those commands as you suggested and referencing them in code via import.meta.env.REACT_APP_MYVAR
Edit: i did just confirm this but it also overrides the env variable set in the .env.server file on the server side. So i need to deploy and build them separately?Yeah, but you don't really want to do it during
wasp start, or even wasp build, instead you want to do it during wasp deploy or if manually running npm build inside of code generated by wasp build. My apologies that we made this so complicated, we will improve it but now it is a bit messy.
It overrides vars in .env.server -> that means you tried during development. Once deploying, server doesn't care about .env.server or anything else on your local machine, it cares only about what secrets you set on your fly machine. So that shouldn't be an issue. For server, you will provide secrets via Fly. For client, you will provide them while running wasp deploy.why wouldnt i want to using with wasp start? I also rely on these variables during development. But it works totally fine now. No worries for the complicated workaround. If it takes longer to implement nicely just consider updating the docs in the meantime as they are kinda misleading and can leave people frustrated if they dont know about this thread 🙂
Thanks anyway for this amazing tool!
I meant to say that you don't really want to prefix commands like
wasp start with env vars during development, because nicer method to do that is specifying them in the .env.client file. But, you could do it if you really wanted to.
I am updating docs right now, will make sure they don't misdirect anybody, and in the future we will also implementing some improvements! Thanks for help and patience with this!
@Gwaggli @fossfighter @jtawf thanks for all the feedback here -> we updated the docs to give much more details info on how to use env vars in Wasp, check it out here https://wasp-lang.dev/docs/project/env-vars, and we also fixed the bug in Wasp where .env.client file is not being picked up!