astFromValue - JavaScript BigInt support

[ardatan]

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

[netlify]

✅ Deploy Preview for compassionate-pike-271cb3 ready!

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	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[github-actions]

Hi @ardatan, I'm @github-actions bot happy to help you with this PR 👋

Supported commands

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]

not sure if we want to merge this 🤔

Numeric integer values larger than 32-bit should either use String or a custom-defined Scalar type, as not all platforms and transports support encoding integer numbers larger than 32-bit.

[ardatan]

@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]

@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.

Oh I see what you mean, its like we are coercing 2147483646n as 2147483646 since it is a valid GraphQL Int after all

[yaacovCR]

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.

[yaacovCR]

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?

See #3973 and #3109.

[yaacovCR]

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