Create a new rust project from VSCode (cargo new / cargo init)

[joshka]

Something that I regularly do is create new rust projects (e.g. for testing out some functionality, bug testing, writing a demo etc.) Right now, the process for this is to have a terminal pointing at my root projects folder, run cargo new project-name, then open code pointing at the project (code project-name or Cmd+O, navigate and open).

This should be simpler and provided within VSCode.

For comparison / implementation ideas. The Java plugin for VSCode has a flow that seems reasonable. Select the project type, select the containing folder, select the project name:

Action: Java: Create Java Project also appears in the Explorer No Folder Opened view:

Select Project Type (this would be just as simple as bin/lib for rust projects, but it could be worth considering making this extensible enough to integrate cargo-generate eventually here.)

Select folder (this remembers the last location which was used to create a new project in)

Enter project name:

I searched for a similar issue and didn't find one already - not sure if I've missed it though as this seems like the sort of request which might have come up previously.

[joculatrix]

Unsure if chiming in to agree is helpful or not, but this was definitely a pain point for me too when I was using VSCode for Rust.

[joshka]

Unsure if chiming in to agree is helpful or not, but this was definitely a pain point for me too when I was using VSCode for Rust.

In general I'd avoid +1 type comments, but I raised this issue as a precursor to actually writing the code to implement it, so validating that it is actually useful is helpful feedback. Thanks.

[joshka]

Proposed Plan

Summary

Implement a VS Code extension command that creates a new Cargo project through a guided flow
modeled on Swift/Java-style project creation.

V1 scope:

• Support cargo new only.
• Offer two templates: Binary and Library.
• Make the command available even when no Rust project is open.
• Prompt after creation to decide how the new project should be opened, with a setting to choose a
  default later.
• Do not add cargo init or cargo-generate in this first implementation.

Public Interface Changes

• New command: rust-analyzer.newProject
  • Title: Create New Project...
  • Category: rust-analyzer
• New setting: rust-analyzer.projectCreation.openAfterCreate
  • Type: enum
  • Values:
    • ask (default)
    • open
    • openNewWindow
    • addToWorkspace
  • Behavior:
    • ask: prompt after successful creation.
    • open: open the created folder in the current window.
    • openNewWindow: open the created folder in a new window.
    • addToWorkspace: add the folder to the current workspace if one exists; otherwise fall back
      to open.
• New discoverability surfaces:
  • Command palette entry visible even when inRustProject is false.
  • Explorer welcome entry for empty/no-folder windows.
  • Add a walkthrough step linking to the new command.

Implementation Changes

• Add a new command implementation in the VS Code extension command layer and wire it into the
  central command registry.

• Keep the implementation entirely in the VS Code extension; no rust-analyzer server or LSP
  changes are expected.

• Command flow:

  1. Resolve cargo using the existing toolchain helper.
  2. If cargo cannot be launched, show a clear error and stop.
  3. Show a quick pick for project kind:
     • Binary Application -> cargo new --bin
     • Library -> cargo new --lib
  4. Show a folder picker for the parent directory where the project folder will be created.
  5. Show an input box for the project name.
  6. Validate only the obvious local constraints before running Cargo:
     • non-empty after trim
     • no / or \
     • not . or ..
     • target folder does not already exist in the chosen parent
     • do not attempt to fully reimplement Cargo package-name validation
  7. Run cargo new with cwd set to the selected parent folder and the chosen name as the final
     argument.
  8. On failure, surface stderr/stdout in an actionable error message.
  9. On success, compute the created folder URI and apply post-create behavior from the setting or
     prompt.

• Post-create prompt behavior when projectCreation.openAfterCreate = ask:

  • In an empty window: offer Open and Open in New Window.
  • In a window with existing workspace folders: offer Open, Open in New Window, and Add to Workspace.
  • If the user dismisses the prompt, creation still succeeds and no further action is taken.

• Post-create execution:

  • open: vscode.openFolder with reuse current window.
  • openNewWindow: vscode.openFolder with force new window.
  • addToWorkspace: workspace.updateWorkspaceFolders(...).
  • After addToWorkspace, explicitly trigger rust-analyzer.reloadWorkspace once so the
    already-running extension/server discovers the new Cargo workspace.

• Scope and product decisions:

  • Do not force --vcs; respect Cargo defaults.
  • Do not create extra files beyond what Cargo creates.
  • Do not persist a rust-analyzer-specific “last used parent folder” in v1. Rely on the native
    VS Code/OS picker behavior instead, because this convenience is non-essential, adds
    state/precedence/invalid-path decisions, and can be added later without affecting the command
    surface.
  • Keep the template list fixed to Binary and Library for v1. Do not add extension points or
    settings for extra templates; richer scaffolding such as cargo-generate should be handled by
    a separate extension/plugin rather than expanding this command’s scope.

Test Plan

• Add unit tests for the extracted local validation helper:

  • rejects empty string
  • rejects . and ..
  • rejects names containing separators
  • rejects collisions with an existing child folder
  • accepts normal project names

• Add unit tests for post-create action resolution:

  • ask returns prompt-required path
  • addToWorkspace falls back to open when no workspace is open
  • prompt option mapping resolves to the intended action

• Add unit tests for Cargo argument construction:

  • binary maps to cargo new --bin <name>
  • library maps to cargo new --lib <name>

• Manual smoke tests:

  • Empty VS Code window -> create binary project -> choose Open.
  • Empty VS Code window -> create library project -> choose Open in New Window.
  • Existing single-folder workspace -> create project -> choose Add to Workspace and confirm RA
    discovers it without window reload.
  • Existing multi-root workspace -> create project -> choose each open mode and confirm behavior
    matches the prompt.
  • Failure path with missing/broken cargo -> clear error message.
  • Failure path with Cargo-rejected package name -> Cargo error is shown rather than silently
    swallowed.
  • Explorer empty-state entry launches the same flow as the command palette command.

Assumptions

• V1 excludes cargo init; that can be a follow-up command or a later branch of the same flow.
• Prompting after creation is the safest default for workspace semantics and is easy to simplify
  later if feedback shows the prompt is unnecessary.
• More advanced scaffolding belongs outside this command’s scope; if cargo-generate support is
  wanted, it should live in a dedicated extension/plugin rather than drive template extensibility
  in rust-analyzer.
• The implementation should stay centered on the existing extension-side surfaces:
  • editors/code/src/commands.ts
  • editors/code/src/main.ts
  • editors/code/package.json

Disclosure

I used Codex/AI tooling to help research comparable editor behaviors and draft/refine this plan.

I have reviewed the resulting plan and consider it a reasonable plan for the feature.

I also checked several other extensions to ground the expected behavior and tradeoffs here,
including Swift, Java, Python, Go, and .NET.

[joshka]

Implementation note from wiring this up:

While implementing Create New Project..., I found that the initial version of the command was using raw process.env both to resolve cargo and to run cargo new, rather than the effective rust-analyzer environment.

I fixed the new-project flow to use rust-analyzer.server.extraEnv consistently for both path resolution and command execution.

There also appears to be a broader extension-side inconsistency worth investigating separately:

• some code paths explicitly merge server.extraEnv before spawning tools
• some already pass an env through to cargoPath(...)
• but cargoPath(...) was still mostly resolving against the VS Code process environment rather than the supplied env

I adjusted cargoPath(env) so that, when an env is provided, it now resolves cargo using that env's CARGO, PATH, and CARGO_HOME-derived state rather than falling back immediately to the host process environment.

I have not tried to audit every extension code path that launches Rust tooling yet, so there may still be other places where process-environment assumptions leak through. This is just a note to capture the observation for later investigation if more environment-related edge cases show up.

[joshka]

Implemented in #22103