JSON.parse / JSON.stringify replacement

[hgraphql]

Reviver and replacer functions modify already processed values. A parse and stringify option would allow for use cases such as utilizing the json-bigint library for parsing a technically valid json string response to a javascript object. Here's how it might look master...hgraphql:graphql-ws:master

[enisdenjo]

The only reason why I am "against" replacing the JSON.parse/stringify is because the requirement of the GraphQL over WS spec is that the messages must be JSON. Meaning, if we allow custom parsers/stringifiers - we give room for differently formatted messages (not JSON basically).

However, I do understand your point but am not that convinced. 😬

Are there significant performance implications?

[hgraphql]

If there's only an option for a custom parser and not a stringifier, there wouldn't be room for differently formatted messages, only the interpretation of those messages. Though I'm not sure that's a complete answer, rather a response to the concern.

The only real alternative to this is to overwrite JSON.parse.

From a performance standpoint, use cases that don't use this option won't be materially affected.

Additionally, I think a user passing that option can be expected to understand that the function they pass produces valid results.

In my opinion, I don't think tying the library to the standard widely used javascript JSON implementation is necessary to be conformant to the spec, though understand if in practice this is not a wide enough use case.

[enisdenjo]

I understand your points, I think they make sense. Are you willing to open a PR?

[hgraphql]

Yep, I can make a PR