feat: Export print from graphql.web

[GauBen]

Summary

Re-export the minimal print function from graphql.web for smaller bundle size.

Set of changes

The graphql function exposed by gql.tada uses graphql.web#parse under-the-hood, which is a lightweight version of graphql#parse. I'm building a minimal graphql client, and to send a proper graphql query, the document needs (does it?) to be stringified. I'm using graphql#print, but using graphql.web#print produces a bundle 4kB smaller.

# With import { print } from "graphql";
❯ du -sh /home/gautier/escape/dropping-zeus/.svelte-kit/output/client/_app/immutable
120K    /home/gautier/escape/dropping-zeus/.svelte-kit/output/client/_app/immutable

# With import { print } from "@0no-co/graphql.web";
❯ du -sh /home/gautier/escape/dropping-zeus/.svelte-kit/output/client/_app/immutable
116K    /home/gautier/escape/dropping-zeus/.svelte-kit/output/client/_app/immutable

The goal of this PR is to make this print function available with import { print } from "gql.tada"; like parse.

[changeset-bot]

🦋 Changeset detected

Latest commit: 832d5bf

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

[kitten]

Just a question, why aren't you depending on @0no-co/graphql.web's print directly? I'm not entirely convinced that re-exporting it here is the right thing to do per se

[kitten]

nit: if we do go for it, I'd instead add a re-export here explicitly:

export { print } from '@0no-co/graphql.web';

The indirection of import+export causes some older versions of some bundlers some trouble when treeshaking.

[GauBen]

Just pushed that instead

[GauBen]

If I install @0no-co/graphql.web directly, gql.tada#parse might be of a different version than @0no-co/graphql.web#print, because @0no-co/graphql.web is not declared as a peer dependency but as a direct dependency

[GauBen]

To address this issue, many libraries in the graphql ecosystem require installing and managing graphql by the end user: https://github.com/dotansimha/graphql-yoga/blob/7eddf1ced3cc89646109f6d05cbcc6438eee9044/packages/graphql-yoga/package.json#L48-L50

[kitten]

gql.tada#parse might be of a different version than @0no-co/graphql.web#print,

That's fine though. Assuming both dependents keep the version relatively up-to-date in terms of major versions (of which we won't have any in the foreseeable future), any package manager should deduplicate this dependency. The exception here are just some edge cases, for which deduping scripts exists. But I'm only really aware of this causing issues in legacy Yarn v1 versions, which is a common problem resolved with yarn-deduplicate.

This also isn't really an issue per se, because gql.tada doesn't rely on print, so even if duplicates are installed, there's no consequences for that in a properly tree-shaken output bundle.

I'm not saying that that's perfect, but I'm not 100% sure passing through an unrelated function makes sense 🤔

cc @JoviDeCroock: any opinions on this?

[JoviDeCroock]

I think we should not export print from this project, if you need print (not in scope of this project) you can always import it from the same location as we are or import it from graphql-js if you prefer using that (and aliasing). Just re-exporting feels confusing to me because we don't alter the AST in a way that can't be printed by a different library nor do we enhance print.

[GauBen]

because we don't alter the AST in a way that can't be printed by a different library nor do we enhance print.

If compatibility is guaranteed, then this PR is not necessary! Thanks for your time and answers, closing this