Conversation
There was a problem hiding this comment.
Pull request overview
This PR implements support for TypeSpec namespaces by mapping them to Rust sub-modules, fundamentally restructuring how generated code is organized within crates. The code model now tracks emitted artifacts in a hierarchical module structure rather than a single flat crate, with each namespace translated to a corresponding sub-module hierarchy.
Changes:
- Refactored code model to support hierarchical module containers (Crate and SubModule types)
- Updated type adaptation to distribute models, enums, unions, and clients across appropriate modules based on their TypeSpec namespace
- Modified import path generation to correctly reference types across module boundaries
Reviewed changes
Copilot reviewed 98 out of 679 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/typespec-rust/src/tcgcadapter/adapter.ts | Adds namespace-to-module mapping logic and distributes types across modules |
| packages/typespec-rust/src/codemodel/crate.ts | Introduces ModuleContainer type and SubModule class for hierarchical organization |
| packages/typespec-rust/src/codemodel/types.ts | Adds module field to Model, Enum, and DiscriminatedUnion types |
| packages/typespec-rust/src/codemodel/client.ts | Adds module field to Client and ResponseHeadersTrait types |
| packages/typespec-rust/src/codegen/use.ts | Updates import path generation to handle cross-module references |
| packages/typespec-rust/src/codegen/codeGenerator.ts | Implements recursive code generation for sub-modules |
| packages/typespec-rust/src/emitter.ts | Updates file writing logic to support nested module directories |
| packages/typespec-rust/src/utils/utils.ts | Adds buildImportPath utility for constructing qualified import paths |
| Various test files | Updates test imports to reflect new module structure |
heaths
left a comment
There was a problem hiding this comment.
A few questions and thoughts, but otherwise LGTM. To note, I'm basing much of this off a previous commit where you prototyped how this looks. Sampling of generated code seems fine, but since I don't know inherently what the TypeSpecs for each of these crates says to do, I can't really judge whether they are correct or not.
That said, the block is because we know Storage isn't right, so we should probably resolve that first. I imagine that will make this PR much smaller and negate having to have a future large PR changing many/most things back to what they should be.
The code model has been refactored so that emitted artifacts are tracked in the crate and zero or more sub-modules for that crate. Added module info to adapated types so we can create the correct import statement across modules. This also required updating the Use helper to take a module param during construction. Improved the detection logic for deleting directories that contain generated code as there can now be multiple directories under src.
9236cbc to
bb67d54
Compare
The code model has been refactored so that emitted artifacts are tracked in the crate and zero or more sub-modules for that crate. Added module info to adapated types so we can create the correct import statement across modules. This also required updating the Use helper to take a module param during construction.
Improved the detection logic for deleting directories that contain generated code as there can now be multiple directories under src.
Fixes #130