Better TOML types #6656
Better TOML types #6656
Conversation
these are the types that may come out of a toml parser, not the types that may be put in a toml serializer inspired by type-fest's Json types
|
|
| @@ -0,0 +1,4 @@ | |||
| export type TOMLTable = {[Key in string]: TOMLValue} & {[Key in string]: TOMLValue|undefined}; | |||
There was a problem hiding this comment.
We'd prefer the capitalization of TomlTable. See https://docs.deno.com/runtime/contributing/style_guide/#naming-convention
There was a problem hiding this comment.
The second part {[Key in string]: TOMLValue|undefined} looks strange to me. Is it possible for key to be undefined? Is that spec compliant?
| @@ -131,18 +132,21 @@ export class Scanner { | |||
| // Utilities | |||
| // ----------------------- | |||
|
|
|||
| function success<T>(body: T): Success<T> { | |||
| function success<T extends TOMLValue|void>(body: T): Success<T> { | |||
|
Run |
|
We currently don't accept a new feature directly, but we'd like to accept it as unstable feature first (See https://github.com/denoland/std/blob/main/.github/CONTRIBUTING.md#suggesting-a-new-feature ) Let's keep the return type of |
| for (const parse of parsers) { | ||
| const result = parse(scanner); | ||
| if (result.ok) return result; | ||
| } | ||
| return failure(); | ||
| }; | ||
| }) as unknown as any; |
There was a problem hiding this comment.
This needs // deno-lint-ignore no-explicit-any directive before this line to pass lint check. See the deno lint output
No description provided.