WIP config parser - #1561
Conversation
|
| /** @internal */ | ||
| export function isTableShapeInput(input: unknown): input is TableShapeInput { | ||
| if (!isPlainObject(input)) return false; | ||
| if (Object.keys(input).some((key) => !tableInputShapeKeys.includes(key as (typeof tableInputShapeKeys)[number]))) |
There was a problem hiding this comment.
we do an isPlainObject check first because Object.keys can have some funky behavior for non-objects:
| expectTypeOf(output).toEqualTypeOf(expectedOutput); | ||
| expectTypeOf(output).toMatchTypeOf(expectedOutput); |
There was a problem hiding this comment.
what's the difference between toEqualTypeOf and toMatchTypeOf?
|
Closing for now. We added a small incremental improvement in #1826 until we can get to the full config overhaul and will likely start fresh when we get to it. |
2 participants
I started playing around with #994 and at the time was trying to refactor some of our config parsing, but realized I was fighting Zod most of the time. I didn't realize it until well into refactoring that Zod doesn't carry through strong types (i.e. string literals from const types), so you have to both define the Zod type/validation/parsing and the TS transformation.
This seemed like a lot more than we need right now, especially if we feel good about leaning on TS for most of the validation, so I started a new config parser that is pure TS and carries strong types. It's made up of small composable pieces that should hopefully make it easier to maintain, extend, etc.
I'm sure we can extract some common patterns into a Zod-like interface, but we can figure that out later.
TODO: