Replies: 1 comment 2 replies
-
Hi @acidoxee, Just to clear out some ambiguity before digging further, when saying:
Do you mean mandatory when the configuration gets validated or, are the configuration types level (with Looking at codegen configuration handling code, it seems that Have you tried defining export default {
projects: {
projectA: {
schema: {
projectA: {
loader:
"/absolute/path/to/monorepo/config/codegen/schemas/loader.js",
},
},
extensions: {
codegen: {
debug: true,
verbose: true,
generates: {
"packages/projectA/schema.graphql": { plugins: ["schema-ast"] },
"packages/app/src": {
config: {
defaultScalarType: "unknown",
immutableTypes: true,
namingConvention: {
enumValues: "change-case-all#constantCase",
},
scalars: {
DateTime: "string",
JSONObject: "Record<string, unknown>",
},
skipTypename: true,
strictScalars: true,
useTypeImports: true,
dedupeOperationSuffix: true,
},
plugins: ["typescript-operations", "typed-document-node"],
preset: "near-operation-file",
presetConfig: {
baseTypesPath: "~#graphql/projectA/__generated__/graphql",
extension: ".ts",
folder: "__generated__",
},
documents: ["packages/app/src/pages/projectA/**/*.tsx"],
},
"packages/app/src/graphql/projectA/__generated__": {
config: {
defaultScalarType: "unknown",
immutableTypes: true,
namingConvention: {
enumValues: "change-case-all#constantCase",
},
scalars: {
DateTime: "string",
JSONObject: "Record<string, unknown>",
},
skipTypename: true,
strictScalars: true,
useTypeImports: true,
dedupeOperationSuffix: true,
},
plugins: [],
preset: "gql-tag-operations-preset",
presetConfig: { augmentedModuleName: "graphql-request" },
documents: ["packages/app/src/pages/projectA/**/*.tsx"],
},
},
},
},
},
// ...
}; |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi there 👋
My team has several GraphQL schemas and servers split across services in a single monorepo codebase. We're not tackling federation/stitching any time soon, so those schemas are all independent from each other. More and more teams are popping their own schemas, and we'd like to centralize codegen to our monorepo's root to ease orchestration and factorization, since we still follow the same guidelines everywhere. Aside from pure API calls from our clients, our frontend app also consumes these schemas in different places.
We exclusively use custom loaders to load each schema with codegen, because:
ts-node
andgraphql-codegen
. So we leverage a lightning fast SWC build step in custom loaders to generate the schemas in JS, which is actually part of the same build process we use for our prod setup, so it's very simple. Until now, the entire codegen process never takes more than 2-3 seconds ⚡Until now, each schema's codegen was separate, and this all worked well. But when we tried to centralize everything and use multi-project config, we were surprised to see that the root
schema
field of each project config did not abide by the same rules as theschema
field in theextensions.codegen
location. While we can use custom schema loaders in the latter, it seems we can't in the former. And since that parameter seems mandatory, we're stuck.We've tried putting an empty value in the root
schema
field, likeschema: ''
orschema: []
, and continue to define our custom loaders in the codegen extension location, but none of that seem to work. We always end up with a very vague[FAILED] Invalid Codegen Configuration!
error right when starting codegen, just after the[STARTED] Parse Configuration
debug message.So a few questions here:
graphql-config
seem to indicate we can't use complex schema pointers with custom loaders, and giving it empty values doesn't seem to workFor reference, here's the (reduced) multi-project config we generate with our homemade helpers:
Some help would be much appreciated 🙏
Beta Was this translation helpful? Give feedback.
All reactions