[GSoC 2026] Support SPM Templates in VS Code

Development GSoC
1

Hello,

I'm Alisher, a third-year Information Systems student at KBTU (Almaty, Kazakhstan). I have experience with TypeScript and Swift, mainly iOS development with SwiftUI/UIKit. I recently had a small fix merged into the repo (PR #2126) and I'm interested in the "Support SPM Templates in VS Code" project for GSoC 2026.

I've set up a local development environment and have been reading through the codebase and SE-0500. Here's where I am so far.

My Understanding

The project adds GUI support for the new SwiftPM template system in the VS Code extension. Right now, createNewProject.ts uses a Quick Pick with hardcoded package types and calls swift package init --type. SE-0500 introduces custom templates that are executables built with swift-argument-parser, accepting user input and generating project files.

The way I see the wizard working:

  1. User provides a template source (git URL, local path, or registry identifier)

  2. Extension runs the template with --experimental-dump-help to get a ToolInfoV0 JSON schema describing all arguments, options, and subcommands

  3. A webview renders that schema as a form, mapping argument kinds to text fields, checkboxes, dropdowns

  4. Collected values get passed back as CLI args to swift package init --type <name> --url <source>

The extension already has a webview for DocC preview (the DocumentationPreviewEditor + bundled JS under src/documentation/webview). It creates a WebviewPanel with bundled JS and bidirectional message passing. I plan to follow this as the reference pattern for the template wizard.

Questions

  1. SE-0500 describes templates as a "branching decision tree". In ToolInfoV0, a command can contain nested subcommands, each with its own arguments. For example, a template offering both a server and a cli path would have different options per branch. Should the wizard handle this as a multi-step flow (pick subcommand, fill options, back/next), or as a single page that dynamically shows/hides fields based on selection?

  2. The current schema is ToolInfoV0, but SE-0500's Future Directions mentions ongoing work on ToolInfoV1 and OpenCLI as successors. Is it reasonable to target ToolInfoV0 directly for now, or worth adding an abstraction layer between the JSON parser and the UI from the start?

  3. Should this be a new command alongside the existing Create New Project, or should that command be extended? The current flow there doesn't have a natural place for template URL input, so a separate command might be cleaner, but keeping all project creation in one place has its own logic too.

@willpaceley @matthewbastien, would appreciate your thoughts on these.

Thanks,

Alisher

3 Likes
2

Hello Alisher!

Thank you for your interest in the SPM Templates project! It sounds like you're on the right track. I discussed with @willpacely and here's our response to your questions:

  1. It's up to you as a contributor to investigate potential solutions and come up with an appropriate proposal based on your findings. We don't want to lean in any particular direction since we haven't looked into all of the possibilities ourselves. Once you have something more concrete with options and their pros/cons then we can definitely discuss which ones are better.
  2. Great question! There won't be much of a change between ToolInfoV0 and ToolInfoV1 as far as we've been made aware. We can just work with V0 for now and deal with any changes that may come later.
  3. We're leaning towards adding functionality to the existing create new project command. Perhaps an additional option in the template selection that brings the user into the webview. Again, this is something that we're open to suggestions for and is up to you to decide on!

If you have any other questions don't hesitate to reach out. We'd love to chat more with you about this and can give some early feedback on your proposal.

1 Like
3

Thank you, @matthewbastien and @willpaceley!

Good to know about V0. Extending the existing command makes sense. Looking at getProjectTemplates(), I can see how it feeds the QuickPick, so there's a natural spot to add a template entry that opens the webview instead of the standard type/folder/name sequence.

The part I want to focus on first is how the wizard should represent the subcommand tree from ToolInfoV0, since SE-0500 templates can define nested argument structures. I'll compare a few approaches with tradeoffs and post a writeup. Once I have a proposal draft ready I'd like to share it with you for early feedback.

4

I studied the codebase and looked at how comparable extensions handle this. I found 3 approaches for the template configuration UI:

1. Sequential QuickPick (Vapor pattern)

Each template argument becomes a QuickPick or InputBox shown one at a time, similar to how the Vapor VS Code extension handles project creation. Consistent with how createNewProject.ts works today, minimal new code. Downside: subcommand branching becomes awkward since the user steps through options without seeing the full picture, and back-navigation is hard to do cleanly.

2. Webview wizard

A webview panel with step navigation: pick template source, select subcommand path, fill arguments, review, generate. The existing DocC preview webview in the extension gives a solid architectural reference for this. Handles branching decision trees naturally, can show all related arguments in context. More code to build and maintain, but a new esbuild entry point would follow the same build setup as the DocC webview.

3. Hybrid

QuickPick for initial steps (source selection, subcommand choice), webview only for the argument configuration step when the template has many options. Simpler templates stay entirely in QuickPick.

I am leaning towards option 2. SE-0500 templates can have nested subcommands with many arguments each, and a webview gives the most room to render that properly. The DocC webview already proves this pattern works in the extension, and a new esbuild entry point would follow the same build setup.

One thing I need to figure out for the proposal: how the extension gets the ToolInfoV0 schema to render the form. I looked at the template system implementation in SwiftPM PR #9211 - TemplatePluginCoordinator.dumpToolInfo() calls the template plugin with --experimental-dump-help and decodes the JSON into ToolInfoV0, but this happens inside the swift package init flow. There is no separate CLI command that outputs just the schema. swift package show-templates lists template names, not argument schemas.

For the wizard, I need the schema before prompting so that the webview can render the form. I see two approaches: (A) the extension fetches the template repo, builds it, and calls the executable with --experimental-dump-help directly to get the schema; or (B) the proposal includes a SwiftPM-side change, like a subcommand that does fetch + build + dump-help and outputs ToolInfoV0 without running the full init flow. Does the project scope include proposing a SwiftPM interface like (B), or should the extension handle schema retrieval independently?

Working on the proposal draft now, will share it for early feedback soon.

5

@matthewbastien @willpaceley
bumping in case this got lost - the A vs B question on schema retrieval is the main open point before I can finalize the proposal scope.

6

Hey @xlmtvv , thanks for the gentle nudge. I’m working on a response, but I’m waiting on confirmation from a colleague to ensure I’m giving accurate information to you.

For the time being, I think it’s safe to operate under the assumption that we’ll need to use a methodology like you described in choice “A”. Note that there are asynchronous operations here so it would be good to consider the resulting user experience in your proposal. Thanks for digging into this!

7

Hi again @xlmtvv , the plan is to obtain the ToolInfoV0 schema via calling swift package init with --experimental-dump-help

So, the initial call to SwiftPM to get the requisite data to drive the template wizard will look something like this: swift package init --url https://path/to/a/package --experimental-dump-help

That would return the JSON representation of the decision tree and would be used to prompt for the user’s choices to the template options. Then those choices will need to be passed back to swift package init again with a separate invocation at the end of the wizard flow to actually create the template from the package.

Good question! Please let us know if any other questions come up while you finish drafting your proposal.

1 Like
8

@willpaceley Thanks, that makes sense! Will share the draft soon.

9

@willpaceley @matthewbastien I've completed a draft proposal and would appreciate any early feedback before the deadline: Support SPM Templates in VS Code - Google Docs

10

Hey @xlmtvv, thanks for drafting a proposal together. I discussed this with @matthewbastien this morning and we have a couple general recommendations:

  1. You included a lot of code examples and implementation details, which while useful to consider for the proposal, aren’t necessary to include. It’s best to focus on high-level implementation plans, architectural decisions, and user experience considerations. We’ve found in our experience that code-level implementation details can quickly change once you begin coding, so it’s wise to not plan at that level.
  2. In a similar vein, we have encouraged everyone to err on the side of brevity for their proposals. 30 pages is a lot of content for a proposal, and similar to a large PR, it can be overwhelming to accurately review when there are too many aspects to comment on.

We appreciate you reaching out for feedback!

1 Like
11

@willpaceley Thanks a lot, really appreciate you taking the time! I'll trim it down and cut the code and tag you again once it's updated.

12

@willpaceley @matthewbastien Thanks again for the feedback, I've revised the proposal based on your suggestions. Trimmed it from 31 pages down to 18, removed the code snippets, and focused on the high-level design and UX decisions. Would really appreciate another look if you have a moment: Support SPM Templates in VS Code - Google Docs