Add error message when user doesn't specify env vars in `wasp build start` #3412

sodic · 2025-11-24T13:51:29Z

Description

Fixes #3307

Type of change

🔧 Just code/docs improvement
🐞 Bug fix
🚀 New/improved feature
💥 Breaking change

Checklist

sodic · 2025-11-24T14:07:05Z

waspc/cli/src/Wasp/Cli/Command/BuildStart/Config.hs

+  userClientEnvVars <-
+    liftIO $
+      combineEnvVarsWithEnvFiles (Args.clientEnvironmentVariables args) (Args.clientEnvironmentFiles args)
+  when (null userClientEnvVars && null userServerEnvVars) $ throwError noEnvVarsSpecifiedErrorMsg


Since:

Our output is pretty noisy and warnings easily get lost

And @cprecioso said:

There's no reasonable situation in which there wouldn't be any environment variables, as at a minimum we'd require the DATABASE_URL.

I decided to throw an error instead of a warning. This is how it looks like:

Potential caveats:

What if the user wants to test how their system behaves when it lacks all env vars? They'd have to pass in a dummy env var just to satisfy our check.

Reviewers: Let me know what you think. Do you think I should log a warning instead?

Seems reasonable to have error and not warning.

What if the user wants to test how their system behaves when it lacks all env vars?

I don't think we need to support that usecase

sodic · 2025-11-24T14:16:38Z

waspc/src/Wasp/Util/Terminal.hs

 styleCode :: String -> String
-styleCode = applyStyles [Bold]
+styleCode "" = ""
+styleCode str = ansiEscapeCode ++ getAnsiCodeFor Bold ++ str ++ ansiEscapeCode ++ ansiResetBoldDimCode


I had to change this because the applyStyles command is too agressive - it resets all the styles, not just the ones it applied.

Here's an example, this is what happens when I use the old version of styleCode inside an error message:

True! I think when I was implementing it, I was just using the general reset code. Which now that you say this, doesn't sounds great hah, because you can't envelop one style with another style.

I see you instead used a specific reset (I dind't even know those exist, awesome).
Why not, while at it, fix the applyStyles function so it resets specific ansii codes, and fix it for good, instead of doing this exception here? Sounds like a simple fix?

I tried it, it was too fiddly to fix and test (some do have their own reset codes, others don't, different treatment for colors and styles, etc.). Details explained here: #3412 (comment). And I'll create an issue.

Also, I'd probably rather use a library for it then implement it here, and that's a seprate discussion which also kind of started in that other thread.

waspc/cli/src/Wasp/Cli/Command/BuildStart/Config.hs

sodic · 2025-11-24T14:43:52Z

waspc/src/Wasp/Util/Terminal.hs

 applyStyles [] str = str
 applyStyles _ "" = ""
-applyStyles styles str = foldl' applyStyle str styles ++ ansiEscapeCode ++ ansiResetCode
+applyStyles styles str = foldl' applyStyle str styles ++ ansiEscapeCode ++ ansiResetAllCode


As mentioned in the other comment, this command is too agressive. ansiResetAllCode removes all the styles including the ones this command didn't apply, which makes it unsuable in all pre-styled text (e.g., error messages).

There are more specific reset codes depending on what you want to reset (source). Unfortunately, only styles (bold, underline) have specific reset codes. Colors only have "reset all."

Anyway, we should:

Ideally find a library that does this for us.

If that's impossible, refactor our internal library:

Differentiate between style and color

Implement something like minimalResetFor :: Style -> String or do something even better to get more control.

Encapuslate ansiEscapeCode. Callers shouldn't have to import both getAnsiCodeFor and ansiEscapeCode. They are never used independently.

I'll create an issue for this.

Together with #3403, I was thinking that we for sure need to either use a library, or make ourselves some API like

errorMessage = CliMsg $ Bold "Wasp Server: " <> Yellow appName <> " is not defined"

and then we compute the ansi codes at print time (or strip them if needed)

It seems prettyprinter and prettyprinter-ansi-terminal is what optparse-applicative uses, we might want to reuse too.

We could define default color that is used to reset colors, and then specific resets for styles, that would probably work well enough for now.

I remember I was looking at other libraries, but I think I found them complicated or didn't like the API, so I did it manually, that it is simple enough. But I am ok for using library of course.

@cprecioso you are suggesting we basically decorate the text with metadata but then later decide how to interpret it (style it, not style it, ...).
I like that, it sounds very nice. I am only wondering if it might complicate things too much, since these are not strings then, and we can't use normal functions to operate on them or print them. But maybe that is ok: because once we add ansi codes in, they are also not normal strings hah, so better not to be able to just simply operate on them. Yeah, I like this, it is semantically correct.

sodic · 2025-11-24T14:45:15Z

waspc/cli/src/Wasp/Cli/Command/BuildStart/Config.hs

+          ++ styleCode "wasp build start"
+          ++ " without specifying any environment variables for the started apps (client and server)."
+          ++ "\nThis is a mistake. Run "
+          ++ styleCode "wasp build start --help"


It would be nice if I could draw the help command (i.e., wasp build start --help) without hardcoding it, but I don't think I can?

Maybe using Options.Applicative.execParserPure can make the parser output the help text.
IMO this is nice-to-have but not key, so I'd try it and see if it can be easily done, skip it otherwise.

What does it mean you could "draw" it? Aha, you mean refer to it somehow, so if its exact invocation changes, this is still correct?

Hm, yeah that would be really nice. We could certainly refactor our system to support this, but probably not worth it now.

cloudflare-workers-and-pages · 2025-11-24T15:47:54Z

Deploying wasp-docs-on-main with Cloudflare Pages

Latest commit:	`40032af`
Status:	✅ Deploy successful!
Preview URL:	https://b65c0c60.wasp-docs-on-main.pages.dev
Branch Preview URL:	https://filip-env-var-message.wasp-docs-on-main.pages.dev

View logs

waspc/cli/src/Wasp/Cli/Command/BuildStart/Config.hs

cprecioso · 2025-11-25T09:05:13Z

waspc/cli/src/Wasp/Cli/Command/BuildStart/Config.hs

+  userClientEnvVars <-
+    liftIO $
+      combineEnvVarsWithEnvFiles (Args.clientEnvironmentVariables args) (Args.clientEnvironmentFiles args)
+  when (null userClientEnvVars && null userServerEnvVars) $ throwError noEnvVarsSpecifiedMsg


something to think about:
if the user passes client envs but not server envs, that's incorrect. the opposite is probably fine. maybe we serve our users better by only checking server envs.
I'm open to being convinced otherwise.

Hm, I didn't want to bake too many assumptions about how other parts of Wasp, or their app and its env vars work. Perhaps they have a client env var that's essential as well?

So my idea was to verify "Did the user manage to get at least one env var to one of the apps?"

If the answer is "no," then something is wrong and we warn them.

If the answer is "yes," then they know what to do, they know about the flags, and knowing about one flag makes the other obvious. If they forgot some (or all) necessary variables, the runtime will warn them.

We muddied the waters here by verifying env vars after resolution (discussion at #3412 (comment)), meaning we do perform a part of the runtime's job, but I don't think we should do more than that.

Martinsos

Quick review as per invite, I will let @cprecioso do the main reviewing/approving, I just commented on couple of things I might be relevant for.

Martinsos · 2025-11-27T19:54:40Z

waspc/ChangeLog.md


+### 🔧 Small improvements
+
+- `wasp build start` now errors when users forget to specify environment variables ([#3412](https://github.com/wasp-lang/wasp/pull/3412))


errors

I thought we are just warning them? Are we sure we want to actually error, is that a bit too strong?

Discussed here. Resolve this thread please and reply there if necessary :)

Martinsos · 2025-11-27T19:59:42Z

waspc/cli/src/Wasp/Cli/Command/BuildStart/Config.hs

+        $ "You called "
+          ++ styleCode "wasp build start"
+          ++ " without specifying any environment variables for the started apps (client and server)."
+          ++ "\nThis is a mistake. Run "


This is a mistake.

Hah this made me laugh. Sounds very short/harsh/robotic somehow.

Couldn't we offer some more information? I think we should explain why this is a mistake -> obviously they don't know, and while just telling them this is a mistake is a first step, but a bit extra info would be nice (even if full explanation is in wasp build start --help).

Hm, what do you suggest we say? I personally wouldn't add anything else but am open to suggestions and will very likely accept them.

obviously they don't know

I'd argue that they do know that not sending env vars is a mistake. They just maybe don't know how to send them. Parts of this are already discussed here: #3412 (comment)

Btw, I managed to refer to the help command's text and now this is my output:

So you can suggest improvements on that. I can't change anything that comes after "Available options." That comes from the parser.

Martinsos · 2025-11-27T20:00:48Z

waspc/cli/src/Wasp/Cli/Command/BuildStart/Config.hs


    serverUrl' = defaultDevServerUrl
+    noEnvVarsSpecifiedMsg =
+      CommandError


So we are going for error, not for warning? I saw you say in another comment it will be warning + it makes sense to me it is warning. I can see it being an error though if we are 100% sure they might not have done this on purpose (are we?).

Discussed here. Resolve this thread please and reply there if necessary :)

Add error message when user doesn't specify env vars

f967778

sodic temporarily deployed to fly-deploy-test November 24, 2025 13:51 — with GitHub Actions Inactive

Fix ansi escape code problems

937a32a

sodic temporarily deployed to fly-deploy-test November 24, 2025 14:02 — with GitHub Actions Inactive

Rename the error message to be more general

4e9902f

sodic commented Nov 24, 2025

View reviewed changes

sodic added 2 commits November 24, 2025 16:45

Merge branch 'main' into filip-env-var-message

fd807da

Update changelog

00e00e5

sodic temporarily deployed to fly-deploy-test November 24, 2025 15:47 — with GitHub Actions Inactive

sodic commented Nov 24, 2025

View reviewed changes

waspc/cli/src/Wasp/Cli/Command/BuildStart/Config.hs Show resolved Hide resolved

Update e2e tests and fix warnings

d5d5041

sodic temporarily deployed to fly-deploy-test November 24, 2025 16:25 — with GitHub Actions Inactive

Fix changelog formatting

2ade096

sodic temporarily deployed to fly-deploy-test November 24, 2025 16:47 — with GitHub Actions Inactive

sodic marked this pull request as ready for review November 24, 2025 16:47

sodic requested review from Martinsos and cprecioso November 24, 2025 16:47

FranjoMindek changed the title ~~Add error message when user doesn't specify env vars~~ Add error message when user doesn't specify env vars in wasp build start Nov 24, 2025

cprecioso reviewed Nov 25, 2025

View reviewed changes

Martinsos reviewed Nov 27, 2025

View reviewed changes

sodic added 2 commits December 4, 2025 16:27

Make small improvements

14f9d4f

Merge branch 'main' into filip-env-var-message

5e0a177

sodic had a problem deploying to fly-deploy-test December 4, 2025 15:41 — with GitHub Actions Failure

Trigger CI

40032af

sodic had a problem deploying to fly-deploy-test December 4, 2025 19:41 — with GitHub Actions Error

Fix type error after merge

df8467b

sodic temporarily deployed to fly-deploy-test December 4, 2025 19:47 — with GitHub Actions Inactive


		### 🔧 Small improvements

		- `wasp build start` now errors when users forget to specify environment variables ([#3412](https://github.com/wasp-lang/wasp/pull/3412))

Uh oh!

Add error message when user doesn't specify env vars in wasp build start #3412

Are you sure you want to change the base?

Add error message when user doesn't specify env vars in wasp build start #3412

Uh oh!

Conversation

sodic commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Type of change

Checklist

Uh oh!

sodic Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sodic Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cprecioso Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Martinsos Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cloudflare-workers-and-pages bot commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying wasp-docs-on-main with Cloudflare Pages

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Martinsos left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sodic Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sodic Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sodic Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Add error message when user doesn't specify env vars in `wasp build start` #3412

Add error message when user doesn't specify env vars in `wasp build start` #3412

sodic commented Nov 24, 2025 •

edited

Loading

sodic Nov 24, 2025 •

edited

Loading

sodic Dec 4, 2025 •

edited

Loading

cprecioso Nov 25, 2025 •

edited

Loading

Martinsos Nov 27, 2025 •

edited

Loading

cloudflare-workers-and-pages bot commented Nov 24, 2025 •

edited

Loading

sodic Dec 4, 2025 •

edited

Loading

sodic Dec 4, 2025 •

edited

Loading

sodic Dec 4, 2025 •

edited

Loading