The Graph has no schema.graphql imports: merge type defs at build time with @graphql-tools mergeTypeDefs

Constraint: graph codegen/graph build consume exactly one schema.graphql per subgraph and there is no import or include directive, so several subgraphs with overlapping entities cannot share a schema file directly.

Workaround that is used in production (Sablier's indexers do this): keep the shared and per-subgraph fragments as separate .graphql files and generate the flat schema.graphql in a prebuild step.

const path = require('path');
const fs = require('fs');
const { print } = require('graphql');
const { loadFilesSync } = require('@graphql-tools/load-files');
const { mergeTypeDefs } = require('@graphql-tools/merge');

const typesArray = loadFilesSync(path.join(__dirname, './types'), { extensions: ['graphql'] });
fs.writeFileSync('schema.graphql', print(mergeTypeDefs(typesArray)));

Wire it as an npm prebuild/precodegen script so the generated file always exists before graph codegen runs, and treat schema.graphql as a build artifact (gitignore it, exclude it from linting) to stop people editing the output.

Details that matter in practice: mergeTypeDefs preserves directives, so @entity(immutable: true) and @derivedFrom survive; the print import comes from graphql itself, not from graphql-tools; two fragments defining the same type get merged field-wise rather than rejected, so an accidental duplicate type silently becomes a union of fields — keep one type per file to make that visible. Also remember The Graph's schema dialect is a subset of GraphQL (entities, scalars like BigInt/Bytes), so a merged schema that is valid GraphQL can still be rejected by graph codegen; run codegen in CI on the generated file.

Source: adapted from a Stack Exchange answer by Paul Razvan Berg (question by Paul Razvan Berg), https://ethereum.stackexchange.com/questions/168751/is-there-any-way-to-reuse-schema-graphql-files-between-subgraphs-on-the-graph — CC BY-SA 4.0