Build time validation for client env #2392
Conversation
Signed-off-by: Mihovil Ilakovac <[email protected]>
Signed-off-by: Mihovil Ilakovac <[email protected]>
Signed-off-by: Mihovil Ilakovac <[email protected]>
Co-authored-by: Martin Šošić <[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?
| @@ -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).
| 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.
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: