Charles BochetandGitHub
b456f79167
## Reduce type leakage between GraphQL schemas ### Why Twenty runs two separate GraphQL schemas: **core** and **metadata**. NestJS's `@nestjs/graphql` uses a global `TypeMetadataStorage` that accumulates all decorated types across all modules. When each schema is built, every registered type leaks into both schemas regardless of which module it belongs to. This means the core schema's generated TypeScript (`generated/graphql.ts`) contained ~2,700 lines of types that only belong to the metadata schema (and vice versa). This creates confusion about type ownership, inflates generated code, and makes it harder to reason about which API surface each schema actually exposes. ### How **1. Patch `@nestjs/graphql` to support schema-scoped type resolution** - **(Already done)** Added a `resolverSchemaScope` option to `GqlModuleOptions`, allowing each schema to declare a scope (e.g. `'metadata'`) - `ResolversExplorerService` now filters resolvers by a `RESOLVER_SCHEMA_SCOPE` metadata key, so each schema only sees its own resolvers - `GraphQLSchemaFactory` now performs a **reachability walk** (`computeReachableTypes`) starting from scoped resolver return types and arguments, only including types that are transitively referenced — handling unions, interfaces, and prototype chains - Type definition storage and orphaned reference registry are cleared between schema builds to prevent cross-contamination **2. Register `ClientConfig` as orphaned type in metadata schema** Since `ClientConfig` is needed in the metadata schema but not directly returned by a resolver, it's explicitly declared via `buildSchemaOptions.orphanedTypes`. **3. Regenerate frontend types and fix imports** - `generated/graphql.ts` shrank by ~2,700 lines (types moved to where they belong) - `generated-metadata/graphql.ts` gained types like `ClientConfig` that were previously missing - ~500 frontend files updated to import from the correct generated file
How to patch a dependency
yarn patch-commit -s does not work in our monorepo. Use the workflow below instead.
New patch
yarn patch <package-name>
# Yarn prints a temp folder path — edit files there, then:
yarn patch-commit <temp-folder> > packages/twenty-server/patches/<package+name+version>.patch
yarn install --mode update-lockfile && yarn install
Reference the patch in packages/twenty-server/package.json:
"<package-name>": "patch:<package-name>@<version>#./patches/<package+name+version>.patch"
Updating an existing patch
yarn patch -u <package-name> # extract with current patches applied (PATCHED)
yarn patch <package-name> # extract clean original (CLEAN)
# Edit files in PATCHED, then copy them into CLEAN
yarn patch-commit <CLEAN> > packages/twenty-server/patches/<package+name+version>.patch
yarn install --mode update-lockfile && yarn install