I’m Niyati, and I’ve been exploring the vscode-swift extension internals. I’ve drafted a proposal for a Schema-Driven Template Wizard to bring a first-class scaffolding experience to the IDE.
The Problem: Currently, using SwiftPM templates in VS Code requires leaving the editor for the CLI, which creates friction for new developers and masks the power of the template system.
The Proposed Solution: Instead of a static UI, I am proposing a dynamic Wizard that uses swift package --experimental-dump-help as the single source of truth. The extension will parse the JSON schema at runtime to generate a validated, native-feeling form.
Technical Highlights of the Proposal:
State Machine Architecture: Using a pure transition function to manage the Wizard's lifecycle, ensuring predictable UI states.
Robust IPC Protocol: A typed discriminated union protocol for Extension Host ↔ Webview communication, including stale-response mitigation using requestId tagging.
Resilient Subprocess Management: Platform-specific handling for subprocess termination (SIGTERM/SIGKILL logic for Windows/Unix) and a fallback "kill switch" via user settings.
Parser Heuristics: A dedicated parseKind logic to map CLI arguments (flags, enums, paths) to VS Code UI components.
I’ve focused heavily on making this project measurable and architecturally sound to ensure it aligns with the high standards of the Swift toolchain.
Hey @NJ-012 , thanks for reaching out for feedback on your proposal. I took a cursory glance and noted a few inaccuracies that conflict with the state of the codebase, one notable one is the mention of an “existing telemetry infrastructure” which doesn’t exist. As I’m sure you can understand, we can only provide feedback on proposals that contain accurate analysis of the project.
I also recommend trying to err on the side brevity, as a 19 page proposal is a lot to digest for this project idea!
Thanks for the direct feedback. You're right—in my effort to be thorough, I included some broad architectural assumptions (like the telemetry mention) that don't reflect the specific 'lean' nature of your codebase. I also agree that the current draft is far too dense for this project's scope.
I'm going to strip this back significantly. My goal is to produce a much tighter, 5-page technical spec that focuses strictly on the actual schema logic and the VS Code implementation.
I'll spend the next few days auditing the repository specifically to ensure the revised timeline and architecture are perfectly aligned with the existing codebase. I appreciate the steer on brevity!
I've attached the revised proposal above for reference:
Comments are open on the document. If you have a moment before the submission deadline, I'd genuinely appreciate any feedback on the revised approach — particularly on the schema retrieval recommendation (Option A) and the createNewProject.ts integration point, since those are the two areas I'm least certain are aligned with what the team has in mind.
No pressure if timing doesn't allow it — I wanted to make sure the document was accessible in case it's useful.