dotansimha / dotansimha/graphql-code-generator

Remove need for babel or swc plugin on client preset for reducing bundle size/code splitting

Open
#9,988 22 comments 22 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
11.3k
Forks
1.4k
Avg merge
1d 1h
Merged PRs (30d)
23

Description

### Is your feature request related to a problem? Please describe.

Yes, it's related to a problem. In a site with a large number of client side queries, we get a very large graphq.ts bundle, just to support types. These types should not add ANY weight to the site.

### Describe the solution you'd like

I'd like for the generated graphq.ts file to simply use a different format, so it doesn't generate this giant blob.

### Describe alternatives you've considered

I can manually edit this thing so that it generates very minimal code like so:

```typescript
import * as types from "./graphql";

type QueryMap = {
"query GetUser($id: ID!) { user(id: $id) { name } }": typeof types.GetUserDocument,
"query GetUsername($id: ID!) { user(id: $id) { username } }": typeof types.GetUsernameDocument,
};

// Overloaded function signatures
export function graphql(source: TSource): QueryMap[TSource];
export function graphql(source: string): unknown;

// Function implementation
export function graphql(source: string) {
return source;
}
```

The effort to do this was simple - I used a multi-cursor selection to grab the types, and just pasted them as the return type for the function interfaces, then again for the union type in the graphql function implementation. Easy peasy - should be similarly easy to implement in the code gen.

### Is your feature request related to a problem? Please describe.

Yes, it's related to the bloat you get from including 2 copies of largish strings, which can't be code-split with tree shaking.

The solution doesn't present any problem, but the heuristics are different. In this code, it simply passes the string defined by the developer from their graphql file, back out. I see very little downside from doing this, especially if your build pipeline is set up to always regenerate the types. But it is different. In the current implementation, the graphql function returns the result of a lookup in a hash table. but the effects should generally be the same - the string you get back from that hash tables, is the same string you passed the function. In the new implementation, it just isn't in the bundle twice, and isn't in the bundle in a way that can't be tree shaken. I see mostly upside, and very little downside (or no downside) here.

AND - I no longer need to use a babel or SWC plugin, which I can't get to work anyway... (And you guys don't need to maintain them any more, or deal with tickets like these...)

It's pure gravy.

### Update:
The original example I provided didn't quite do the same thing as the generated code currently does - this one should.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.