Persisted document custom hash function

[nahn20]

Description

This features allows for customization of the hashAlgorithm configuration for persisted documents in the client preset. This mitigates the need to support additional future algorithms beyond sha1 and sha256 and gives developers full flexibility for generating document hashes, unlocking new use-cases.

Related #9994

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

Added three new test cases to client-preset.spec.ts. Ran yarn test client-preset.

• custom hash remove whitespace - This test case demonstrates basic functionality in a human-readable manner. Since the output is just the operation without whitespace, it's easy to tell if the custom hash function is broken.
• custom hash sha256 - This test case replicates the existing test case hashAlgorithm="sha256" to ensure identical results.
• custom hash docs sha512 - This test case demonstrates a realistic, real-world use-case and was chosen as the example for the docs.

Test Environment:

• OS: MacOS
• @graphql-codegen/...:
• NodeJS: v18.18.2

Checklist:

• I have followed the CONTRIBUTING doc and the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[changeset-bot]

🦋 Changeset detected

Latest commit: d4f4468

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[n1ru4l]

@nahn20 Can you please also add a changeset for these changes?

[n1ru4l]

What would happen if the hash function returns the same hash for multiple operations? Should we assert this?

[nahn20]

I think that considering how advanced of a feature that this is, any developer using a custom function should know how to design an effective hash function. I'd be comfortable leaving in this footgun for the sake of full customizability, to account for potential use-cases that we aren't thinking of.

I also think that the cost of a bug here is minimal due to this potential issue being easy to debug. If a developer implements a poor hashing function, then they'll find their GraphQL calls aren't working. They would disable persisted documents, then see they are working again. From there, I have full confidence a developer can debug it down to multiple equal hash outputs by analyzing the mismatched operations.

Additionally, I think this would add a false sense of security. Not all approved operations are guaranteed to be present at generation time (for example, a backend which remotely stores operations from previous client versions).

This functionality is also easy for a developer to implement if they want the extra safety. I don't think this is necessary to build into the preset itself.

[n1ru4l]

Thank you for your contribution!