wasp
wasp copied to clipboard
wasp-lang
feat: separate env vars for server and client
Description
Adds support for .env vars for frontend app. To enable this, Wasp user can add .env.client file which will be passed to web app as .env file.
⚠️ Breaking change: Existing Wasp users have to manually update env filename at wasp root dir from .env to .env.server.
Fixes #675
TODO:
- [x] Check all examples for
env-samplefile and update accordingly. By now found at https://github.com/wasp-lang/wasp/blob/main/waspc/examples/todoApp/sample.env - [x] Update docs at https://github.com/wasp-lang/wasp/blob/main/web/docs/language/features.md#env
Type of change
Please select the option(s) that is more relevant.
- [x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [x] This change requires a documentation update
Hi @shayneczyzewski and @Martinsos - can some one review this?
It still misses some doc and example updates. I added reminders on those to the TODO in the description.
Hi @shayneczyzewski and @Martinsos - can some one review this?
It still misses some doc and example updates. I added reminders on those to the TODO in the description.
Hey there @preshetin! Great work getting a PR open! Martin is on vacation this/next week, but I can give it a first pass on Monday.
Thanks, and be in touch soon.
Thanks @shayneczyzewski and @Martinsos for reviewing this 🙇♂️
My Haskell skills are miserable so even tiny refactoring may take huge amount of time.
I wanted to learn Haskell when I saw someone mention Wasp project in Prisma showcase Slack channel. Then I completed about half of the Learn Haskell by building a blog generator tutorial. Thanks btw for posting this link at Wasp Discord.
- Were you able to find anything in CRA that would allow us to change that
REACT_APP_envar prefix?
@shayneczyzewski CRA does not support changing / removing this prefix, see https://github.com/facebook/create-react-app/issues/2865. There are certainly ways to tweak things during web app generation
Hi @preshetin - thanks for the replies! No worries on the Haskell refactoring timing as you learn it, it can definitely take some time to get used to. I can try to see if I can spend some time pointing you in the right direction for that function DRYing refactor. Part of it is slightly complicated by the StrongPath types. 👍🏻Keep at it though, you are doing great! :D
Sounds good on CRA envar prefix, thanks for confirming and the link!
@preshetin cool that you are learning haskell! I would recommend http://learnyouahaskell.com/ as an initial (free) resource, and building that blog post sounds like a nice project to experiment with. Haskell is a bit scary by reputation but is actually easier than what people say + it teaches you some really interesting concepts. Good place to ask for Haskell help is also r/haskell, but you can also ask in our wasp-lang discord, we have #haskell channel, and no question is too trivial! Btw I hope you got LSP working for this project -> it helps a lot of and makes refactoring in Haskell really nice. If you need help with setting that up let us know although it should be pretty straightforward if you are using visual studio code.
As for this PR -> if you want to give a bit of a try to do that refactoring following @shayneczyzewski 's suggestions, go for it. If on the other hand feel that is a bit too much at the moment, that is also ok -> let us know and we will take it from here and do some final tweaks on the PR before we merge -> you can then also take a look at the result of it, to see what we did.
Thanks @Martinsos and @shayneczyzewski for your feedback.
I removed duplication thanks to Shayne's chunks of code. Hoping someone will review it once again
For now the only thing left is updating the documentation. If the rest is fine I can proceed with that. Hoping it won't take much time
Thanks @Martinsos for the review. Sure I can do those adjustments and also update the docs. Hoping it will be within a day or two
Hey @Martinsos - I've made those adjustments. The only thing left is updating docs. I believe it is in another repo.
Still, it's better to wait with merging until docs are updated
Hey gang, just getting back into it after a few days off. Great progress, @preshetin! It is coming along really nicely! And thanks for the review @Martinsos, I appreciate that!
Can't wait to see how it looks with docs and becomes ready for a final review and merge 🥳
Cool @preshetin , that concludes it, looking good!
Actually, docs are in the same repo, so the best way is to do them also in this PR. You can find them under /web/docs/, and you will specifically be interested in /web/docs/language/features.md, I believe that is the only file you will need to change. To check out how to build the webpage/blog/docs, check web/README.md, and ping us if anything is unclear!
Docs updated. If the wording needs adjusting just let me know or feel free to jump in with your commit.
If all looks good it can be merged I think.
A thought -> what if somebody has .env defined from before, updates Wasp, and doesn't realize .env doesn't do anything any more -> it might take them some time to figure out this is the problem! Maybe we should add a piece of logic that scans for .env file and warns that it is redundant in such case? What do you think @preshetin @shayneczyzewski ? Or should we just ignore it?
A thought -> what if somebody has .env defined from before, updates Wasp, and doesn't realize .env doesn't do anything any more -> it might take them some time to figure out this is the problem! Maybe we should add a piece of logic that scans for
.envfile and warns that it is redundant in such case? What do you think @preshetin @shayneczyzewski ? Or should we just ignore it?
Good question and reminder, @Martinsos. Given that this will break backward compatibility and some other framework norms, I see 3 options off the top of my head:
- [Nothing] We do nothing, and just call it a breaking change (and highlight it prominently in changelog/docs)
- [Warn] We issue a compiler warning if we see a
.envfile in the wasp project dir that it should be a client/server file instead, like you said - [Fix] We treat any
.envas a.env.serverfile and "fix" it for them
I would personally probably lean toward #2. It helps guide both existing users toward the new norm, and new users who may get caught in the future. What do you think @preshetin? Great job so far BTW!
Yes, let's do (2)! @preshetin is this something you would be ok with adding as a final step?
- [Nothing] We do nothing, and just call it a breaking change (and highlight it prominently in changelog/docs)
- [Warn] We issue a compiler warning if we see a
.envfile in the wasp project dir that it should be a client/server file instead, like you said- [Fix] We treat any
.envas a.env.serverfile and "fix" it for them
I would lean either to [Nothing] or [Warn]. Manipulating user's code without explicit asking feels like a bad idea to me.
As to implementation of [Warn], I'm not sure I can do it quickly. So if anyone feels to jump in I am totally fine with that!
Yes, let's do (2)! @preshetin is this something you would be ok with adding as a final step?
@Martinsos I'm afraid it'll take too much time for me. So if we want to ship it faster better for someone to jump in
No problem @preshetin , we can take care of this one! Should be relatively easy by using the function you wrote, the one finds any file in the wasp project dir. Thanks for pushing this PR so far, we will ping you once we are done and merge it!
Yep, thanks again @preshetin one of us will get this across the finish line. Once I wrap up a couple of open PRs, I can take a look. We appreciate your contributions!
Hey @Martinsos and @preshetin, I had a few moments after wrapping some things up to come back and take a look at this. I figured the easiest way to propose the GeneratorWarning addition was to just make a PR based off your branch Peter.
So here it is: https://github.com/preshetin/wasp/pull/1
Please let me know if that makes sense to both of you. Thanks!