Can we please tree shake away graphql from final bundle?

[frederikhors]

I'm using the amazing codeden's typescript-urql plugin.

It works amazingly!

Specifically, using the configuration below I can also generate documentNodes that would allow me to go without all the graphql library in the final bundle and at runtime (there is no need to parse any files as they are all already nodes), or am I wrong?

But I see that urql anyway inserts the parser and more from the graphql library for a total of 43 KB (!!!) (see screenshots).

Can we create an option to take it off? What is it for? My query is compiled at compile time.

Can we do tree shaking of that heavy library?

I have only a few queries and the final bundle is big already for other reasons and the device it has to run on is a low-low-low end one.

Config

schema: ./schema.graphql
generates:
  ./types.ts:
    documents: ./**/*.graphql
    plugins:
      - typescript-urql
    config:
      documentMode: documentNode

Generated code

import { DocumentNode } from "graphql";
// ...
export const MyDocument = {
  kind: "Document",
  definitions: [
    {
      kind: "OperationDefinition",
      operation: "query",
      // ...
    },
  ],
} as unknown as DocumentNode;

[kitten]

It's simply not possible, no, and we've talked about this before in several issues; This basically comes down to leftover dependencies, in other words, we have several files that cannot be removed entirely, namely:

• The parser (graphql/language/parser) cannot be removed. As @urql/core supports both raw strings and precompiled query documents, it must always have the parser available.
• The stringifier (graphql/language/printer) cannot be removed, since it must be used (no matter whether we have raw strings or precompiled queries) to stringify the query document that is sent to the API. This cannot be skipped as we must parse the query, since it's a guarantee to have it available in unstringified form in the exchanges pipeline
• The visitor (graphql/language/visitor) cannot be removed, since it's used to add __typename fields dynamically. This could be done in a precompile step, but again, it isn't done since we support raw strings as inputs.
• there's a single function that Graphcache uses, which is valueFromASTUntyped, but that's a tiny function we'd otherwise have to reproduce anyway.

Now, given that, what's the actual impact;

But I see that urql anyway inserts the parser and more from the graphql library for a total of 43 KB (!!!)

Careful here! 😃 This is simply not an accurate statement, since an absolute number on its own isn't representative of the impact of code. If you're measuring unminified code especially, you'll see numbers that don't tell you anything about what's being delivered to the user. So, strictly speaking we always measure in minzipped (minified + gzipped) as this is a consistent number that gives us an idea of "relative impact". So, in other words, what's the impact of @urql/core without any bits from graphql? 6.9kB minzipped currently, according to Bundlephobia. How does that compare to what we're using from graphql?

Well, luckily, I've got an isolated build of just that. Our imports of interest here are:

export { valueFromASTUntyped } from "graphql/utilities/valueFromASTUntyped.mjs";
export { GraphQLError } from "graphql/error/GraphQLError.mjs";
export { Kind } from "graphql/language/kinds.mjs";
export { parse } from "graphql/language/parser.mjs";
export { print } from "graphql/language/printer.mjs";
export { visit } from "graphql/language/visitor.mjs";

The minzipped size of this is 11.2kB, which assumes you're using Graphcache. Either way, that's pretty good for what we get. A trick we recommend here is to stub out the parser file to an empty one, if you're pre-compiling. While this is an extreme measure, this would get you down to 5.55kB, which is absolutely negligible.

Now, the real question here apart from the technical requirements and details above though is probably "But what do we want to do about this?" And the answer is simple, we don't want to require users to precompile queries and we don't want gql/parse to always be used manually, as it simply confuses beginners and isn't suitable for many other cases. Instead, we're currently thinking about how to limit the size of graphql in front-end applications itself.

To that end what I'm currently working on is a "graphql lite" package, which will continue to function normally and as expected in front-end applications when it's swapped into the build process or codebase. This is codenamed "graphql-web-lite" and would bring the 11.2kB figure down to 5.44kB (3.19kB without the parser), which is then absolutely in the realm of what we deem acceptable.

Now, the closing advice here for now is, if you're precompiling, you can already alias graphql/language/parser to an empty file in your bundling/build process. However, if you're measuring impact, make sure you measure in minzipped and not absolute sizes, since otherwise you'll get meaningless comparisons (the impact of 100kB unminified/raw over 50kB isn't +100%, since that's not representative of neither transport costs and parsing costs)

I have only a few queries and the final bundle is big already for other reasons and the device it has to run on is a low-low-low end one.

Well, I'd really doubt that 3.2/3.5% (albeit, measured with the above problems, I've mentioned) is the big driving factor here, unless all the other dependencies and modules are <3% each. But yea, if you really need to squeeze some size out here, do the aliasing trick, and in the future we'll have a package that we'd like to recommend people to alias in their frontend build process to reduce the impact of the graphql standard library.

[kitten]

I'm pretty sure npm doesn't support npm: aliases gracefully. This is because npm often fails peer dependencies rather than accepting them when they don't match the version range. Coincidentally, I just published the package under 15.5.1000 which is the version scheme it'll use going forward, which should match the peer dependency range and hence work with npm just fine.

Edit: re publishing the repo; like I said, it's a super early WIP experiment and hence the repo won't be public just yet.

[frederikhors]

I can confirm it works amazingly with: "graphql": "npm:[email protected]".

[frederikhors]

I will follow this project and I can PR for docs in urql if you like, when will it be.

[frederikhors]

I spoke too soon.

This is the error when building if I use "graphql": "npm:[email protected]" and not the aliasing trick.

[vite]: Rollup failed to resolve import "graphql/language/visitor.mjs" from "node_modules\@urql\core\dist\urql-core.mjs".
This is most likely unintended because it can break your application at runtime.
If you do want to externalize this module explicitly add it to
`build.rollupOptions.external`
Error: [vite]: Rollup failed to resolve import "graphql/language/visitor.mjs" from "node_modules\@urql\core\dist\urql-core.mjs".

[frederikhors]

I just found a bug that made me crazy!

With graphql-web-lite if you have nested types it doesn't fetch __typename.

Example:

players() {
  nodes {
    id
  }
  page {
    cursor
  }
}

it doesn't fetch __typename neither for each Player in nodes nor for Page.

Using graphql (removing alias trick) it works.