feat(scalars): distinct input/output codegen types#3086
Draft
ifeanyi-ugwu wants to merge 6 commits into
Draft
Conversation
CountryCode, Currency and CountryName accept only a fixed ISO set, so the generated resolver type should be that string-literal union rather than a bare `string`. The union and the jsonSchema `enum` are derived from a single `as const` source list, and each scalar carries precise generics. Matching stays case-insensitive and returns the input value unchanged.
Several scalars parse to one type but accept a wider set for serialization, so the single codegenScalarType could only ever name one of them — and sometimes named the wrong one: USCurrency claimed `string` though resolvers both return and receive `number`. codegenScalarType now consistently carries the resolver-return (output) type, with precise `<TParsed, TSerialized>` generics so the parsed type stays recoverable from the scalar itself. Timestamp's jsonSchema type is corrected to integer to match its numeric wire value.
…enerics The scalars built from inline configs defaulted to `GraphQLScalarType<unknown, unknown>`, hiding their real types. Each now declares `<string, string>` or `<number, number>` to match what parseValue and serialize actually handle, so the parsed and serialized types are visible from the scalar itself. Behavior is unchanged; SE's string guard became an assertion so it narrows without a cast.
…and returned differ
Scalars whose parsed (input) type is narrower than the accepted resolver-return
(output) type declare codegenScalarType as { input, output }: DateTime, Date,
Time, Timestamp, Byte, URL, BigInt, Port, Latitude and Longitude (DateTimeISO
and Long inherit). For example DateTime emits
{ input: Date; output: Date | string | number } and Port emits
{ input: number; output: string | number }.
Depends on the object-form codegenScalarType support added in
graphql-code-generator#10893; older codegen reads the extension as a single
string.
Contributor
|
This would be a breaking change imo. So it probably needs a major release. |
The object form is a format change to codegenScalarType, not a value change. Released graphql-code-generator reads the extension as a string and cannot parse the object, so regenerating against current codegen breaks.
Contributor
Author
Agreed, i've bumped the changeset to major. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2554. Emits distinct
input(parsed) andoutput(resolver-return) codegen types for the 12 scalars where they differ, via the object form ofcodegenScalarType— e.g.DateTime: { input: Date; output: Date | string | number },Port: { input: number; output: string | number }.Draft — not ready to merge
Two dependencies:
7715ef4c): 12codegenScalarTypelines plus a changeset.codegenScalarTypesupport in graphql-code-generator (dotansimha/graphql-code-generator#10893), which is unreleased. Older codegen reads the extension as a single string, so adopting the object form is a breaking change for consumers until that ships.What it does
Scalars whose parsed value is narrower than the values a resolver may return now declare both positions instead of collapsing them into one union:
DateDate | string | numberDateTime,TimestampDateDate | stringDate,TimeBufferBuffer | stringByteURLURL | stringURLbigint | numberbigint | number | stringBigIntnumberstring | numberPort,Latitude,LongitudeDateTimeISOandLonginherit their base configs.