Build-time validation for client env #2392
Conversation
Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>
Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>
| -- 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
| if (config.command !== 'build') { | ||
| return | ||
| } |
There was a problem hiding this comment.
I'd say this check can be first thing in the handler, exit as soon as possible
| try { | ||
| return schema.parse(data) | ||
| const validatedEnv = schema.parse(env) |
There was a problem hiding this comment.
We can just use schema.safeParse() and avoid the try/catch. We can also just return the safeParse value, no need to create our own {type,data} type.
| @@ -49,3 +49,12 @@ export type _Parameters<T extends (...args: any) => any> = T extends ( | |||
| ) => any | |||
| ? [FirstParam, ...Rest] | |||
| : Parameters<T>; | |||
|
|
|||
| // PRIVATE API (Vite config) | |||
| export type Result<Data> = { | |||
There was a problem hiding this comment.
We can use z.SafeParseReturnType
| @@ -3,8 +3,8 @@ import { defineEnvValidationSchema } from 'wasp/env' | |||
|
|
|||
| export const serverEnvValidationSchema = defineEnvValidationSchema( | |||
There was a problem hiding this comment.
Just a note for future development, we could accept any Standard Schema-conforming definition. It's quite easy and Zod is already compliant so it wouldn't be a breaking change.
There was a problem hiding this comment.
This is a great idea, I always felt bad for forcing the user to use a specific validation library. Does that mean that the user would be able to give us their schema in e.g. Valibot and we would be able to validate it with Zod?
There was a problem hiding this comment.
Yep, although we wouldn't even need to call Zod, the Standard Schema already defines the methods for parsing inside its namespace.
// `schema` is any normal zod, arktype, valibot, etc schema, no special adapters needed
const result = schema["~standard"].validate(rawData)
if (result.issues) throw new Error(...)
const data = result.valueMore info on their page https://github.com/standard-schema/standard-schema#how-do-i-accept-standard-schemas-in-my-library
There was a problem hiding this comment.
Not complaining, but any reason for this change? 😜
| } | ||
|
|
||
| console.error(`${redColor}${validationResult.message}`) | ||
| // Exit early if we are in build mode, because we can't show the error in the browser. |
There was a problem hiding this comment.
This comment probably refers to L24, right?
| console.error(`${redColor}${validationResult.message}`) | ||
| // Exit early if we are in build mode, because we can't show the error in the browser. | ||
| process.exit(1) |
There was a problem hiding this comment.
Why print and exit instead of throwing an error? process.exit() does not let cleanup code run.
| // Exit early if we are in build mode, because we can't show the error in the browser. | ||
| process.exit(1) | ||
| }, | ||
| configureServer: (server) => { |
There was a problem hiding this comment.
I'm guessing this is because we can't just run this validation and throw the error inside the actual application, so we send it the error to display after the fact, right?
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: