Name | Link |
---|---|
🔨 Latest commit | 62f92fe |
🔍 Latest deploy log | https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/670bb7bed4d9de000852eb12 |
😎 Deploy Preview | https://deploy-preview-4088--compassionate-pike-271cb3.netlify.app |
📱 Preview on mobile |
To edit notification comments on pull requests, go to your Netlify site configuration.
Hi @ardatan, I'm @github-actions bot happy to help you with this PR 👋
Please post this commands in separate comments and only one per comment:
@github-actions run-benchmark
- Run benchmark comparing base and merge commits for this PR@github-actions publish-pr-on-npm
- Build package from this PR and publish it on NPM@saihaj Isn't it for Int
scalar type? However, this PR doesn't change that behavior. Int
still doesn't support larger integers. This PR just allows to use bigint
type of JavaScript just like number
and string
. So it is not the size of the number but the type of it.
If Int
supports 32-bit numeric values in string format, it should allow the same values in bigint
format as well right?
Same for ID
and `Float but without 32-bit limit.
@saihaj Isn't it for
Int
scalar type? However, this PR doesn't change that behavior.Int
still doesn't support larger integers. This PR just allows to usebigint
type of JavaScript just likenumber
andstring
. So it is not the size of the number but the type of it. IfInt
supports 32-bit numeric values in string format, it should allow the same values inbigint
format as well right? Same forID
and `Float but without 32-bit limit.
Oh I see what you mean, its like we are coercing 2147483646n
as 2147483646
since it is a valid GraphQL Int after all
In terms of default values, that use case should probably be re-examined after #3814 lands, which should hopefully be soon! We are halfway-through the stack.
I suppose we will need to support conversion from BigInt to Int/Float when possible if the received JSON is parsed with a BigInt supporting parser. I think it probably would require some discussion at the WG in terms of whether to include it, but I would be in favor.
In terms of output, I am of two minds in terms of whether we should be supporting conversion from bigint to int, because that means that a custom scalar probably should have been used, in case the value was greater than the int threshold. Maybe it's better to fail overall?
For conversion to string or id, I imagine we would want to support it, I can't see why not?
96 | 121 | value: '123', | |
97 | 122 | }); | |
98 | 123 | ||
124 | expect(astFromValue(9007199254740993n, GraphQLFloat)).to.deep.equal({ |
The change in type of this test is because astFromValue is not safe, set to be replaced by valueToLiteral()
for all remaining uses in #3814
But a bigint of sufficient size, -- as far as I know -- cannot be converted to a JS float.
We also in this PR do not properly handle GraphQLFloat scalar parsing and serialization of small BigInts, I will push a failing test to demonstrate what I mean.
We also probably should update the logic within the new valueToLiteral()
utility. It's possible that overall we can just delay landing this PR until after #3814
Login to write a write a comment.
This PR adds support for BigInt values to
astFromValue
.It coerces whenever possible instead of failing.
This will also allow custom scalars like https://the-guild.dev/graphql/scalars/docs/scalars/big-int to get a
BigInt
as a default value. Similar to #4085