near-operation-file-preset with fragment masking?

[osdiab]

Hi all, in our project we are using the client-preset with a Hasura GQL schema (read: very big) and our gql documents in TypeScript files. We are finding that when changes to the typescript files cause the giant generated codegen file to be recreated, this causes our editor/lint performance to tank (with typescript-eslint) and also causes the NextJS dev server to become very unstable and slow since it also ends up recompiling a lot of code.

I'm thinking that this impact could be reduced significantly with something like the near-operation-file-preset since only small amounts of code would get regenerated as changes occur, but I was wondering before I sink a ton of time into this, if anyone knows if the fragment masking approach works with that? Because our codebase already bought into that and moving away from it would be both a bummer and also a pain.

(I also tried to move to gql.tada as a way to get around causing typescript changes whenever we change files during development, but turns out for a big Hasura schema it just causes the TypeScript compiler to run out of memory. Sad but perhaps that will get better in the future)

Thanks!

[osdiab]

Happy to say that I found a way to make it work by looking through the source code and understanding it better!

• the source code for the fragment masking plugin is not exported by graphql-codegen as a standalone plugin that's reusable, but the source code is simple enough so I just copy pasted it and made my own custom version of it.
  • that said, I realize that actually it's not even necessary for it to be a plugin - it does not rely whatsoever on your GraphQL schema nor operations so you could potentially just copy paste the generated fragment masking code into a file and not worry about graphql-codegen for generating it at all.
    • the one type it does import from your generated gql types, Incremental, could just be saved in the fragment-masking code itself - export type Incremental<T> = T | { [P in keyof T]?: P extends ' $fragmentName' | '__typename' ? T[P] : never };
    • this makes me think there's a world in which rather than it being generated, graphql-codegen can just export a helper function that unmasks fragments rather than generating it altogether, which would make fragment masking much more accessible
  • I did make an edit to it to allow customizing where it imports graphql types, since the implementation in the client preset just assumes that types will be next to the fragment masking code, which may not be the case now that it's a separate plugin.
• and then there's an undocumented value for the typescript and typescript-operations plugin inlineFragmentTypes config called "mask" that the client preset uses to make the generated typescript code for operations be compatible with fragment masking, so use that.
  • if graphql-codegen just documented this option and exported the fragment masking plugin/functions/types as mentioned earlier, then fragment masking could potentially be compatible with any graphql-codegen setup.

here is a gist showing how to do it:

https://gist.github.com/osdiab/054c4e1c9c7404edd87a38728622df3f

[osdiab]

@charlypoly @n1ru4l @beerose just tagging you as people who worked on fragment masking before but yeah, I get the sense from this dive that fragment masking can be made much more accessible outside the client-preset, so maybe there's an opportunity here to make it more easily usable/composable.