SDL-codegen exploration

[Tobbe]

https://github.com/puzzmo-com/sdl-codegen

1. Try the latest version of SDL Codegen. See if it works, if so, update Cedar's dependencies
2. Experiment with how it works. If I like it, I should fork the repo and update all its dependencies

[lisa-assistant]

Implementation Plan

Goal: Evaluate whether upgrading @sdl-codegen/node from v2.0.1 → v3.x (latest: v3.0.4) works with Cedar's setup, and experiment with adopting it more broadly if the results are promising.

---

Background

Cedar currently has @sdl-codegen/node pinned at v2.0.1 in packages/internal/package.json. It's used behind the experimental flag useSDLCodeGenForGraphQLTypes in cedar.toml. The call site is:

// packages/internal/src/generate/graphqlCodeGen.ts:47–53
const sdlCodegen = await import('@sdl-codegen/node')
const output = await sdlCodegen.runFullCodegen('redwood', { paths })

The v2 API requires a RedwoodPaths shape that includes api.dbSchema — a field that Cedar's getPaths() does not currently expose. This may have been silently dropped or papered over; it's worth confirming in the upgrade process.

The latest published release is v3.0.4 (MIT, published ~a year ago by orta). The package.json in v3 lists these dependencies: @babel/generator, @babel/parser, @babel/traverse, @babel/types, @mrleebo/prisma-ast, ts-morph.

---

Step 1 — Upgrade and check API compatibility

# packages/internal/package.json
-    "@sdl-codegen/node": "2.0.1",
+    "@sdl-codegen/node": "3.0.4",

Then run yarn install and check whether runFullCodegen still exists with the same signature. If the preset: 'redwood' entrypoint is gone or renamed, update the call in graphqlCodeGen.ts:47–52.

Check specifically:

• Does v3 still export runFullCodegen(preset, config)?
• Does it still accept { paths: RedwoodPaths }?
• Does it still require api.dbSchema in the paths object? If so, wire it up from getPaths().api.dbSchema (which doesn't exist yet — you'd need to add it to packages/project-config/src/paths.ts pointing at the Prisma schema file, e.g., path.join(paths.api.base, 'db', 'schema.prisma')).

---

Step 2 — Smoke test

Enable the flag in a test Cedar app:

# cedar.toml
[experimental]
  useSDLCodeGenForGraphQLTypes = true

Then run yarn cedar generate types and confirm:

• No crash
• .d.ts files generated in api/types/ (or wherever sdl-codegen writes them)
• The generated types are correct for a sample SDL + service

---

Step 3 — Evaluate output quality

Compare the generated types from sdl-codegen v3 against the current @graphql-codegen/typescript-resolvers-based output:

• Are resolver types correct (including context, parent, args)?
• Are union/enum types handled properly?
• Does it handle custom scalars?

---

Step 4 — Decide on forking

If the library works but has outdated dependencies or gaps, fork puzzmo-com/sdl-codegen under the Cedar org, update deps, and point packages/internal/package.json at the fork (or publish a @cedarjs/sdl-codegen package).

---

Files to change

File	Change
packages/internal/package.json	Bump @sdl-codegen/node to 3.0.4
packages/internal/src/generate/graphqlCodeGen.ts	Update call if API changed; pass dbSchema if required
packages/project-config/src/paths.ts	Add dbSchema to NodeTargetPaths + getPaths() if sdl-codegen v3 needs it
packages/internal/meta.json	Update the sdl-codegen entry if present

---

Edge cases / risks

• paths.api.dbSchema missing: Cedar paths don't expose a dbSchema field; if v3 requires it you need to add it. The value should be getPaths().api.base + '/db/schema.prisma' (or respect prismaConfig if that moves the schema).
• Output path clash: Confirm sdl-codegen v3 doesn't write to the same api/types/graphql.d.ts that the regular codegen writes — could cause a conflict if both are enabled.
• Watcher API: The v2 return type includes a createWatcher() function — Cedar doesn't currently use it, but confirm it still exists in v3 in case someone wires it up later.

[lisa-assistant]

Self-fix confidence: 5/10

The upgrade itself (bumping the version + checking the API) is mechanical, but I'd only call this a 5 because:

• I can't run yarn cedar generate types end-to-end in the sandbox without a full Cedar project wired to a real DB, so I can't actually validate that the generated output is correct.
• The api.dbSchema mismatch between Cedar's getPaths() and sdl-codegen's expected RedwoodPaths type is a real unknown — I know the field is missing, but I don't know whether v3 actually uses it or just has it in the interface.
• The "should we fork?" decision in step 4 requires human judgment about maintenance appetite.

The mechanical parts (bump version, fix call site, add dbSchema to paths if needed) are confident 9s. The evaluation/decision parts bring the overall score down.