Potential Bundle Size Solution

[nahn20]

The Problem

For larger web projects, the single generated output file for documents has caused issues for bundle size. The Babel and SWC plugins are solutions meant to patch this issue. I haven't personally tried the Babel plugin but I imagine there's additional complexity and debugging in setup. And the SWC plugin, as far as I can tell, has been difficult to maintain, especially across multiple versions of Next.js. Next.js users don't have any good alternatives, and projects with a significant number of documents have to sacrifice loading times due to this arbitrary limitation.

Relevant Issues

• @graphql-codegen/client-preset-swc-plugin not working with nextjs ^14 #9753
• Remove need for babel or swc plugin on client preset for reducing bundle size/code splitting #9988

A Potential (Ugly) Solution

I've put together a somewhat ugly solution to solve the bundle size problem across the board. I've only been using it for my own Next.js project (and weirdly enough a backend service), but I see no reason why it wouldn't eliminate the need for plugins across the board.

Essentially, instead of keeping all the documents inside a single file, I have a hook which parses the output file and shards it into hundreds of files, each containing a single document. For consistency, I've also done it for enums, but I don't think enums cause significant bundle size issues in general. I've kept types in the original file for the sake of implementation ease and because they don't impact bundle size.

I'd consider this to be an ugly solution since there's a significant number of edge cases I've ignored for the sake of getting it working for my own repositories.

Benefits

• This solution completely solves the bundle size problem. Only the queries you're using on that page are included in the bundle (as it should be!)

Tradeoffs

• Existing barrel files no longer work
  • I wasn't using the gql.ts and index.ts files anyways, so I just deleted them
  • I don't believe there's any way to make these work in a bundle-friendly manner
• More Imports
  • I don't consider this to be a massive issue since any good IDE should be able to find the individual document files
• Migration
  • I spent several hours just swapping out imports
  • Migration is extremely tedious (though likely solvable with a script!)

Where do we go from here?

This part, I'm not too sure. I started this thread as a discussion to gauge community interest and potential best paths forward. This solution inherently goes against many of the established conventions of graphql-code-generator. I'd be happy to publish the version that works for my codebase, but considering how many potential edge cases there are when paired with other plugins and configurations, I wouldn't be able to maintain it.

[felix98765]

Hi, could you provide a sample code for the hook please? We also face this issue and would like to take some inspirations.

[nahn20]

Here ya go! You'll want to use this in an afterAllFileWrite hook. Let me know if there's anything I can clarify.

[felix98765]

Thank you!