feat: type safety in sdks rfc 21 #63
Conversation
WalkthroughAdds a new RFC Markdown document titled "Type Safety in SDKs" proposing an end-to-end type-safety workflow for Appwrite SDKs and CLI. The RFC defines ownership, timeline, problem statement, design (CLI-driven init, Zod-typed config, push/pull sync, Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 Fix all issues with AI agents
In `@021-type-safety-in-sdks.md`:
- Around line 162-210: The RFC is missing key sections—populate "Documentation &
Content" with detailed docs for the new CLI commands (appwrite init, appwrite
generate), a usage guide for the generated typed SDK, migration guide for
existing projects, and a full tutorial workflow; expand "Prior art" to compare
with Prisma, Drizzle, Supabase type generation and Firebase approaches and note
lessons; fill "Unresolved questions" with concrete proposals for schema
evolution, generated-code versioning, batch operation error handling (e.g.,
createMany), permissions in generated SDKs, and code formatting/linting; and
extend "Future possibilities" with support for other languages, real-time
type-safe subscriptions, runtime schema validation, and a GraphQL-like query
builder so reviewers can evaluate scope and trade-offs.
- Around line 145-161: Expand the "Reliability (Tests & Benchmarks)" section by
filling the "Scaling", "Benchmarks", and "Tests (UI, Unit, E2E)" subsections:
under "Scaling" describe expected behavior with large schemas (100+ collections
and deep nesting), specify generated file size limits and chunking/segmentation
strategy, and outline the incremental update approach (detect schema diffs,
regenerate only affected modules and update index exports); under "Benchmarks"
add measured generation times for small/typical/large projects, compare runtime
performance and type-safety overhead between the new generated typed SDK and the
current SDK, and report bundle size impact and mitigation strategies
(code-splitting, tree-shaking); under "Tests (UI, Unit, E2E)" define a test plan
to ensure generated types match runtime behavior (type-checking CI step,
snapshotting generated types, and runtime contract tests), list unit and
integration tests for each SDK feature, include automated integration tests for
the "appwrite generate" CLI (end-to-end generation, build, and type-check), and
enumerate edge case tests (circular references, complex nested types,
optional/nullable fields) with expected handling and failure modes.
- Line 143: Fix the typos in the sentence that currently reads "No breaking
changes. Existing type safeyy works as it is, for users who want the type safe
version can opt in by using the new command." — change "safeyy" to "safety" and
hyphenate "type-safe"; also adjust punctuation for clarity so the sentence
becomes grammatically correct (e.g., split into two clauses or add a
conjunction) while keeping the original meaning.
- Line 33: Summary: The phrase "in a semi manner" in the "Push/Pull Sync" line
is grammatically incorrect; replace it with a clearer, hyphenated or rephrased
variant. Fix: update the sentence containing "Push/Pull Sync" and the exact
fragment "in a semi manner" to a correct phrase such as "in a semi-automated
manner" or "partially" (e.g., "Push and Pull commands will sync your entire
configuration (currently this does this in a semi-automated manner)"). Ensure
the revised wording keeps the original meaning and flow.
- Line 127: Fix the grammar in the sentence that starts "The command will auto
detect if server sdk is being used or not (with ability to manually select
either), and generate server side methods too -" by replacing it with a
corrected version: hyphenate "auto-detect" and "server-side", use "whether"
instead of "if", and add necessary articles for clarity (e.g., "the server SDK"
and "the ability"); locate the sentence matching "The command will auto detect
if server sdk is being used or not..." and update it accordingly.
- Line 100: The file 021-type-safety-in-sdks.md contains an incomplete tree
entry represented by the literal text "├──" (the dangling node marker) — either
remove that stray line if no file was intended there or replace it with the
missing filename that should follow the "├──" marker; locate the "├──" token in
the document and either delete the line or complete it with the correct filename
so the file-tree listing is syntactically and semantically correct.
- Line 49: The config uses inconsistent and non-standard naming: "tablesDB" and
"type": "tablesdb" while also using "databaseId", which diverges from Appwrite's
conventional "databases" key; decide whether this is an intentional new term or
a mistake and make names consistent—either rename "tablesDB" to "databases" and
"tablesdb" to the standard type, and keep "databaseId" as-is, or explicitly
document and propagate the new "tablesDB"/"tablesdb" terminology across the
config and code (including any parsing logic that expects "tablesDB") so callers
and validators use the same key names (search for "tablesDB", "tablesdb", and
"databaseId" to update references).
- Around line 107-126: Add a new dedicated section to the RFC that documents the
client-side batch/utility methods shown in the examples (listWithTotal,
createMany, updateMany, deleteMany, upsert on db.users): for each method
describe its behavior (what it returns and whether it maps to multiple
individual API calls vs a single backend call), the intended implementation
approach (client-side loop/wrapper or transactional/atomic backend support),
error handling semantics (how partial failures are reported, whether results
include per-item success/failure details), atomicity guarantees (whether
rollbacks are supported or not), and performance implications (network
round-trips, recommended limits). Also mark these as client-side helpers if no
new API endpoints are introduced and give recommended retry/timeout strategies
and example return shapes so callers know how to handle partial failures.
🧹 Nitpick comments (3)
021-type-safety-in-sdks.md (3)
6-7: Consider linking to a tracking issue.While "No specific issue" is noted, it's generally beneficial to have a GitHub issue for tracking discussions, feedback, and implementation progress for significant features like this.
11-11: Remove unused link reference definitions.The link reference definitions for
[summary],[problem-statement],[design-proposal],[prior-art],[unresolved-questions], and[future-possibilities]are defined but never referenced in the document. Either use them for internal linking or remove them.🔧 Suggested fix
If you want to use them for internal navigation:
See the [design proposal](`#design-proposal`) section for details.Or remove the unused definitions:
## Summary - -[summary]: `#summary`Also applies to: 19-19, 27-27, 178-178, 198-198, 206-206
91-103: Add language specifier to fenced code block.The file structure code block should specify a language (e.g.,
textorplaintext) for proper rendering.📝 Suggested fix
-``` +```text generated/ ├── appwrite.databases.ts
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
021-type-safety-in-sdks.md
🧰 Additional context used
🪛 LanguageTool
021-type-safety-in-sdks.md
[grammar] ~33-~33: Use a hyphen to join words.
Context: ...ration (currently it does this in a semi manner). 3. Generate: `appwrite gene...
(QB_NEW_EN_HYPHEN)
[grammar] ~127-~127: Use a hyphen to join words.
Context: ...estuser2' }); ``` The command will auto detect if server sdk is being used or no...
(QB_NEW_EN_HYPHEN)
[style] ~127-~127: In contexts where ‘if’ is followed by ‘or’, using ‘whether’ may be more appropriate (and formal).
Context: ...' }); ``` The command will auto detect if server sdk is being used or not (with a...
(IF_WHETHER)
[grammar] ~127-~127: Use a hyphen to join words.
Context: ...ally select either), and generate server side methods too - ```typescript await ...
(QB_NEW_EN_HYPHEN)
[grammar] ~143-~143: Ensure spelling is correct
Context: ...ges No breaking changes. Existing type safeyy works as it is, for users who want the ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~143-~143: Use a hyphen to join words.
Context: ...ks as it is, for users who want the type safe version can opt in by using the new...
(QB_NEW_EN_HYPHEN)
🪛 markdownlint-cli2 (0.18.1)
021-type-safety-in-sdks.md
11-11: Link and image reference definitions should be needed
Unused link or image reference definition: "summary"
(MD053, link-image-reference-definitions)
19-19: Link fragments should be valid
(MD051, link-fragments)
19-19: Link and image reference definitions should be needed
Unused link or image reference definition: "problem-statement"
(MD053, link-image-reference-definitions)
27-27: Link fragments should be valid
(MD051, link-fragments)
27-27: Link and image reference definitions should be needed
Unused link or image reference definition: "design-proposal"
(MD053, link-image-reference-definitions)
91-91: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
178-178: Link and image reference definitions should be needed
Unused link or image reference definition: "prior-art"
(MD053, link-image-reference-definitions)
198-198: Link and image reference definitions should be needed
Unused link or image reference definition: "unresolved-questions"
(MD053, link-image-reference-definitions)
206-206: Link and image reference definitions should be needed
Unused link or image reference definition: "future-possibilities"
(MD053, link-image-reference-definitions)
🔇 Additional comments (2)
021-type-safety-in-sdks.md (2)
4-5: Verify the aggressive timeline.The target date is 11 days from the start date. Given the scope of this RFC (CLI enhancements, code generation, typed SDK structure, new batch operations, testing, and documentation), this timeline appears highly ambitious. Consider whether this is realistic or if the target date should be adjusted to allow for:
- Thorough design review and iteration
- Implementation of CLI and generation logic
- Testing across various schema configurations
- Documentation and examples
- Community feedback incorporation
23-23: The terminology is consistent throughout the RFC. Line 23 usestableId, which aligns with the RFC's proposed data structure that consistently uses "tables" terminology (lines 49, 56, 61). There is no inconsistency to address within the RFC itself. ThetableIdreference is correct and intentional as part of this feature's design.Likely an incorrect or invalid review comment.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
ChiragAgg5k
force-pushed
the
feat-type-safety-in-sdks
branch
from
f59ac3d to
c04dc63
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@021-type-safety-in-sdks.md`:
- Line 91: The fenced code block in 021-type-safety-in-sdks.md lacks a language
identifier which prevents proper syntax highlighting; update the block enclosing
the snippet "generated/" to include a language tag (e.g., change ``` to ```text)
so the code fence reads ```text and renders correctly.
♻️ Duplicate comments (5)
021-type-safety-in-sdks.md (5)
49-49: Clarify "tablesDB" naming convention.The configuration still uses
"tablesDB"(line 49) and"type": "tablesdb"(line 56) alongside"databaseId"(line 65). Standard Appwrite configurations use"databases"for database instances. Confirm whether this is intentional new terminology or should align with existing conventions.
33-33: Fix grammar: "in a semi manner".The phrase "in a semi manner" remains grammatically incorrect. Use "semi-automated manner" or "partially" instead.
📝 Suggested fix
-2. **Push/Pull Sync**: Push and Pull commands will sync your entire configuration (currently it does this in a semi manner). +2. **Push/Pull Sync**: Push and Pull commands will sync your entire configuration (currently it does this in a semi-automated manner).
100-100: Remove incomplete line in file structure.Line 100 shows an incomplete entry (
├──) without a filename.🔧 Suggested fix
├── appwrite.teams.ts -├── ├── appwrite.types.ts
117-124: Document batch operation methods.The usage examples show
listWithTotal,createMany,updateMany,deleteMany, andupsertmethods without specification. The RFC must clarify their behavior, implementation approach (client-side loops vs. backend), error handling for partial failures, and atomicity guarantees.
127-127: Fix grammar and style issues.Multiple grammar issues remain:
- "auto detect" → "auto-detect"
- Use "whether" instead of "if...or not"
- "server side" → "server-side"
- Missing article "the" before "ability"
📝 Suggested fix
-The command will auto detect if server sdk is being used or not (with ability to manually select either), and generate server side methods too - +The command will auto-detect whether the server SDK is being used (with the ability to manually select either) and generate server-side methods too:Based on static analysis hints.
🧹 Nitpick comments (6)
021-type-safety-in-sdks.md (6)
23-23: Strengthen the problem statement with more examples.While the
databaseIdandtableIdexample is good, the problem statement would benefit from additional concrete examples showing where type safety is missing (e.g., attribute types in documents, query parameters, permission strings, function parameters).
147-153: Expand reliability testing details.While the Scaling and Benchmarks sections now have content, they could be more specific:
- Scaling: Mention what happens with 100+ collections, deeply nested structures, or very large schemas
- Benchmarks: Provide estimated generation times or bundle size impacts
155-160: Add edge case testing details.The Tests section lists good coverage but should explicitly mention edge cases like:
- Circular references in data structures
- Reserved TypeScript keywords in table/column names
- Very long identifiers
- Special characters in names
- Optional vs required fields
11-11: Optional: Remove or use link reference definitions.The document defines several link references (
[summary]:#summary, `[problem-statement]: `#problem-statement, etc.) that are never used. Either remove these definitions or add corresponding links in the text.Based on static analysis hints.
Also applies to: 19-19, 27-27, 170-170, 178-178, 187-187
89-103: Consider error type generation.The proposed file structure doesn't mention error types. Will the generated SDK include typed error classes for different API error responses (e.g.,
DocumentNotFoundError,ValidationError, etc.)?
44-87: Add validation for circular references.The data structure example shows a straightforward schema, but doesn't address how circular references between collections (e.g., User → Posts → User) will be handled in the generated TypeScript types. Document the strategy for handling recursive types.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
021-type-safety-in-sdks.md
🧰 Additional context used
🪛 LanguageTool
021-type-safety-in-sdks.md
[grammar] ~33-~33: Use a hyphen to join words.
Context: ...ration (currently it does this in a semi manner). 3. Generate: `appwrite gene...
(QB_NEW_EN_HYPHEN)
[grammar] ~127-~127: Use a hyphen to join words.
Context: ...estuser2' }); ``` The command will auto detect if server sdk is being used or no...
(QB_NEW_EN_HYPHEN)
[style] ~127-~127: In contexts where ‘if’ is followed by ‘or’, using ‘whether’ may be more appropriate (and formal).
Context: ...' }); ``` The command will auto detect if server sdk is being used or not (with a...
(IF_WHETHER)
[grammar] ~127-~127: Use a hyphen to join words.
Context: ...ally select either), and generate server side methods too - ```typescript await ...
(QB_NEW_EN_HYPHEN)
🪛 markdownlint-cli2 (0.18.1)
021-type-safety-in-sdks.md
11-11: Link and image reference definitions should be needed
Unused link or image reference definition: "summary"
(MD053, link-image-reference-definitions)
19-19: Link fragments should be valid
(MD051, link-fragments)
19-19: Link and image reference definitions should be needed
Unused link or image reference definition: "problem-statement"
(MD053, link-image-reference-definitions)
27-27: Link fragments should be valid
(MD051, link-fragments)
27-27: Link and image reference definitions should be needed
Unused link or image reference definition: "design-proposal"
(MD053, link-image-reference-definitions)
91-91: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
170-170: Link and image reference definitions should be needed
Unused link or image reference definition: "prior-art"
(MD053, link-image-reference-definitions)
178-178: Link and image reference definitions should be needed
Unused link or image reference definition: "unresolved-questions"
(MD053, link-image-reference-definitions)
187-187: Link and image reference definitions should be needed
Unused link or image reference definition: "future-possibilities"
(MD053, link-image-reference-definitions)
🔇 Additional comments (8)
021-type-safety-in-sdks.md (8)
5-5: Verify the timeline is realistic for this scope.The target date allows only 11 days for a feature that involves CLI changes, SDK generation logic, type generation, documentation, and testing across multiple Appwrite services (databases, auth, storage, functions, buckets, messaging, teams). Given the scope outlined in the RFC—including workflow changes, data structure design, code generation, and comprehensive testing—this timeline may be too aggressive.
143-143: LGTM: Typo and grammar issues fixed.The typo "safeyy" has been corrected to "safety" and "type-safe" is now properly hyphenated. The sentence is now grammatically correct.
161-167: LGTM: Documentation section is now complete.The Documentation & Content section now has concrete deliverables including SDK docs, CLI reference, blog post, and starter template. Good coverage.
168-175: LGTM: Prior art section provides good context.The Prior art section now references relevant projects (Prisma, Supabase, Drizzle) that solve similar problems. This provides helpful context for reviewers.
176-184: LGTM: Unresolved questions are concrete and relevant.The questions around output directory naming, multi-language support, relationship types, and reserved word handling are all pertinent to the implementation.
185-193: LGTM: Future possibilities show forward thinking.The future possibilities (query builders, real-time subscriptions, Zod schemas, watch mode, IDE extensions) demonstrate good planning for evolution of this feature.
107-126: Specify permission handling in generated SDK.The usage examples show CRUD operations but don't demonstrate how permissions will work with the typed SDK. Will permission strings be typed/validated? How will users specify read/write permissions on documents?
34-35: Clarify incremental regeneration strategy.The
appwrite generatecommand is mentioned, but the RFC doesn't specify how incremental updates work. When a developer adds a new collection or modifies a schema, do they need to regenerate everything, or can the CLI detect changes and update only affected types?
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
ChiragAgg5k
force-pushed
the
feat-type-safety-in-sdks
branch
from
c04dc63 to
5e0bd78
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@021-type-safety-in-sdks.md`:
- Around line 11-27: The draft contains unused reference definitions like
"[summary]: `#summary`" and invalid fragment links that don't match the
auto-generated heading ids (e.g., the heading "Problem Statement (Step 1)" will
generate an anchor like "#problem-statement" rather than
"#Problem-Statement-(Step-1)"); remove the unused reference definitions or
update them to match actual heading anchors, and update any links to use the
correct anchor text (or add explicit HTML id attributes to the headings) so
anchors like "problem-statement" and "design-proposal" resolve and the
references are actually used.
♻️ Duplicate comments (2)
021-type-safety-in-sdks.md (2)
42-66: Clarify “tablesDB/tablesdb” vs. standard “databases” naming.This still diverges from existing Appwrite config naming while also using
databaseId. Please confirm whether this is intentional new terminology or align it with standarddatabasesnaming for consistency.
158-180: Document the bulk/utility methods shown in examples.The RFC still lists
createMany,updateMany,deleteManywithout specifying behavior, implementation (client-side loops vs server support), error handling/partial failures, atomicity, or performance implications. Please add a dedicated section defining these semantics.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@021-type-safety-in-sdks.md`:
- Around line 197-202: Update the "### Supporting Libraries" section to list the
actual dependencies needed for the type-generation and validation work: add
`zod` (for config validation and "fully typed with zod" support referenced
earlier), a template engine used in the diff (e.g., `handlebars` or `ejs`) for
codegen templates, and the TypeScript compiler API or `ts-morph` (for
programmatic type generation); also mention any CLI/runtime deps like
`typescript` itself and any dev tooling required. Locate the "### Supporting
Libraries" heading and the "fully typed with zod" sentence to ensure the new
bullet list clearly enumerates `zod`, the chosen template engine,
`typescript`/`ts-morph` (or tsc API), and any other codegen/runtime libs.
- Around line 57-68: The config uses inconsistent terminology: rename the config
key "tablesDB" and the "type" value "tablesdb" to match the API and codegen by
using "databases" and "databases" (or consistently choose the alternate and
update codegen) and update any references to the id field to use "databaseId"
instead of "tableDBId"; specifically, align the JSON config entries (currently
"tablesDB" and "type":"tablesdb") with the generated API file symbol
databases.ts and the factory function createDatabases, and update all
usages/refs to the id field to "databaseId" so names are consistent across
config and codegen.
🧹 Nitpick comments (5)
021-type-safety-in-sdks.md (5)
11-11: Remove unused reference definitions.These reference-style link definitions (
[summary]:#summary``, etc.) are never used in the document and should be removed for cleanliness. If you intended them for navigation, they need to match the actual heading IDs (which include parenthetical text like "(Step 1)") and be used in actual links.Based on static analysis hints.
🧹 Cleanup suggestion
## Summary -[summary]: `#summary` - Appwrite's SDKs are technically typed but not type safe...Apply the same removal to lines 27, 35, 236, 244, and 253.
Also applies to: 27-27, 35-35, 236-236, 244-244, 253-253
97-105: Generated file structure seems incomplete.The file structure only shows database-related files (
databases.ts,types.ts), but the AI summary mentions "apps, databases, auth, storage, functions, etc." If this RFC only addresses database type safety, clarify that explicitly. If it covers all Appwrite services, expand the file structure example to reflect that scope.
211-226: Reliability section adequately addresses concerns.The section now includes scaling, benchmarks, and testing strategy. The "< 1 second" generation claim (line 216) is reasonable for typical projects. However, consider explicitly addressing the edge case of very large schemas (100+ collections with deep nesting) mentioned in past reviews—even if generation is still fast, the generated file size and TypeScript compilation time could become concerns.
242-250: Unresolved questions capture key decisions.The four questions are relevant, and loks0n's comment suggests consensus on question 1 (
./generated/by default, configurable). Consider adding:
- CLI bundling strategy (lines 122-127 show this is still "exploring")
- Bulk operations API implementation details (lines 166-189 lack specification)
These are architectural decisions that should be resolved before merging.
251-259: Clarify "Type-safe query builders" in future possibilities.Line 255 lists "Type-safe query builders with typed filters and field selection" as a future possibility, but lines 156-164 already demonstrate a QueryBuilder with typed filters (
q.equal(),q.greaterThan()). If this refers to enhanced capabilities (e.g., field selection, join support), clarify what's included in the initial release vs. future enhancements.
| "tablesDB": [ | ||
| { | ||
| "$id": "test-db", | ||
| "name": "Testing Database", | ||
| "$createdAt": "2026-01-15T05:47:28.583+00:00", | ||
| "$updatedAt": "2026-01-15T05:47:28.583+00:00", | ||
| "enabled": true, | ||
| "type": "tablesdb", | ||
| "policies": [], | ||
| "archives": [] | ||
| } | ||
| ], |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for databases vs tablesDB patterns in the repository
echo "=== Checking for 'databases' vs 'tablesDB' usage ==="
rg -n 'databases|tablesDB' --type=json --type=md -C 2
echo -e "\n=== Checking file structure of the target file ==="
fd -e md | grep -i "type-safety"Repository: appwrite/rfc
Length of output: 1480
🏁 Script executed:
# Read the full context of the file around the flagged section
echo "=== Full context of 021-type-safety-in-sdks.md around lines 57-105 ==="
if [ -f "021-type-safety-in-sdks.md" ]; then
sed -n '48,105p' "021-type-safety-in-sdks.md"
elif [ -f "rfcs/021-type-safety-in-sdks.md" ]; then
sed -n '48,105p' "rfcs/021-type-safety-in-sdks.md"
else
find . -name "*021*type-safety*.md" -exec sed -n '48,105p' {} \;
fiRepository: appwrite/rfc
Length of output: 1370
Resolve inconsistent terminology in the config structure.
The document claims to "follow the existing appwrite config's data structure," but introduces inconsistent terminology. The config uses "tablesDB" (line 57) with "type": "tablesdb", while the generated API structure references databases.ts (line 102) and uses const databases = createDatabases(client) (line 147). Additionally, database references use "databaseId" (line 73), not "tableDBId". This mismatch must be resolved in the RFC before implementation—either rename "tablesDB" to "databases" throughout the config structure, or justify why the config terminology diverges from the generated API.
🤖 Prompt for AI Agents
In `@021-type-safety-in-sdks.md` around lines 57 - 68, The config uses
inconsistent terminology: rename the config key "tablesDB" and the "type" value
"tablesdb" to match the API and codegen by using "databases" and "databases" (or
consistently choose the alternate and update codegen) and update any references
to the id field to use "databaseId" instead of "tableDBId"; specifically, align
the JSON config entries (currently "tablesDB" and "type":"tablesdb") with the
generated API file symbol databases.ts and the factory function createDatabases,
and update all usages/refs to the id field to "databaseId" so names are
consistent across config and codegen.
| ### Supporting Libraries | ||
|
|
||
| No new libraries required, uses existing: | ||
| - appwrite-cli | ||
| - typescript sdks | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Update supporting libraries list.
This section claims "no new libraries required" but line 40 mentions "fully typed with zod" for the config. Additionally, type generation typically requires dependencies like:
zod(for config validation)- Template engine for code generation
- TypeScript compiler API (if generating types programmatically)
Update this section to list all actual dependencies.
🤖 Prompt for AI Agents
In `@021-type-safety-in-sdks.md` around lines 197 - 202, Update the "###
Supporting Libraries" section to list the actual dependencies needed for the
type-generation and validation work: add `zod` (for config validation and "fully
typed with zod" support referenced earlier), a template engine used in the diff
(e.g., `handlebars` or `ejs`) for codegen templates, and the TypeScript compiler
API or `ts-morph` (for programmatic type generation); also mention any
CLI/runtime deps like `typescript` itself and any dev tooling required. Locate
the "### Supporting Libraries" heading and the "fully typed with zod" sentence
to ensure the new bullet list clearly enumerates `zod`, the chosen template
engine, `typescript`/`ts-morph` (or tsc API), and any other codegen/runtime
libs.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.