Build-time validation for client env #2392
Conversation
Signed-off-by: Mihovil Ilakovac <[email protected]>
Signed-off-by: Mihovil Ilakovac <[email protected]>
| -- Vite plugins | ||
| genFileCopy [relfile|vite/validateEnv.ts|], |
There was a problem hiding this comment.
I commented on this here: #2442 (comment)
| -- Server env | ||
| genServerEnv spec, | ||
| -- Client env | ||
| genClientEnvSchema spec, |
There was a problem hiding this comment.
I'd say these comments are redundant. The function names are descriptive enough.
| genServerEnv spec, | ||
| -- Client env | ||
| genClientEnvSchema spec, | ||
| genFileCopy [relfile|client/env.ts|] |
There was a problem hiding this comment.
I suggest grouping schema and env files under the same generator function:
-- top level
genSharedEnvFiles spec,
genServerEnvFiles spec,
genClientEnvFiles specThere was a problem hiding this comment.
How come we created this new file?
I understand Vite needs to import the schema, but it could have imported it from the old file, right?
There was a problem hiding this comment.
The old file had a side effect on import because ensureEnvSchema validates the env vars and throws an error if there is something wrong. So I split the schema and the checking logic into two different files.
| @@ -9,6 +9,7 @@ | |||
| }, | |||
| "include": [ | |||
| "vite.config.ts", | |||
| "./src/ext-src/vite.config.ts" | |||
| "./src/ext-src/vite.config.ts", | |||
There was a problem hiding this comment.
Don't forget to kick this one out on merge.
| {=! Private: [client] =} | ||
| "./env/validation": "./dist/env/validation.js", | ||
| {=! Private: [client, sdk] =} | ||
| "./client/env/schema": "./dist/client/env/schema.js", |
There was a problem hiding this comment.
Please update the google sheet with these guys if you haven't :)
| } from 'wasp/env/validation' | ||
| import { clientEnvSchema } from 'wasp/client/env/schema' | ||
|
|
||
| const redColor = '\x1b[31m' |
There was a problem hiding this comment.
redColor is defined in two places.
We also have yellowColor defined in providers/dummy.ts.
Maybe it's time we created an ansiColors file that exposes a function (or more) for coloring text into ANSI colors? I know there's a dependency for this but I don't think it's worth it. We can create a small module supporting only the colors we currently need, and build from there.
Also, when dealing with ASNI escape sequencees, the protocol is to reset the color after outputting the colored text. This is done by appending an additional escape sequence after the text, see this post for details).
Our code never does this. That might be OK since our colors are always used with console.log (which I'm guessing resets all colors when flushing the output). But, if we end up building the coloring module, it shouldn't assume the caller is using console.log (perhaps they want to output different text in different colors in a single line).
There was a problem hiding this comment.
I'll make a separate PR for this 👍
There was a problem hiding this comment.
Did it here: #2547
| export type EnvValidationResult<Env> = { | ||
| type: 'error', | ||
| message: string, | ||
| } | { | ||
| type: 'success', | ||
| env: Env, | ||
| } |
There was a problem hiding this comment.
This is a nice candidate for universal/types (it's already generic enough, all that's necessary is to change its name to Result).
You can optionally make the message type generic as well (like in Either), but I don't think it's necessary. I already have it in the Wasp TS config package, but unfortunately there isn't a way to reuse that here.
Martinsos
changed the title
Signed-off-by: Mihovil Ilakovac <[email protected]>
|
@cprecioso ready |
This replaces build-time env validation
validate-env.mjsscript (removed in #2362) with a simple Vite plugin. It removes thedotenvdep requirement and uses the same Zod schema that the runtime validation uses.In development it displays an overlay in the user's browser if the env var validation failed:
When building it exits the build process:
Not covered by this PR: #2645