[VS Code] Support for Apps in Workspaces

[chiaramooney]

Problem Statement

The WinApp VS Code extension currently assumes the open workspace folder is the app project root. Every command (init, restore, pack, cert generate, etc.) calls getWorkspacePath() which returns workspaceFolders[0].uri.fsPath and passes that as the cwd to the CLI.

This forces users into an awkward workflow:

1. Monorepo / nested project — The app lives at repo/apps/my-app/ but the user has repo/ open for git, editing, etc. They must re-open VS Code rooted at repo/apps/my-app/ just to use WinApp commands.
2. Multi-app repo — A repo contains frontend/, backend/, and shell/ apps. The user wants to target one at a time without switching workspace roots.
3. VS Code multi-root workspaces — The user has several folders in a .code-workspace file. Today only workspaceFolders[0] is used; the others are ignored.

---

Goals

• Allow WinApp commands to target an app project directory that is not the workspace root.
• Support repos with multiple app projects.
• Maintain zero-config simplicity when the workspace root is the project root (current behavior).
• Work with both single-folder and multi-root VS Code workspaces.

Non-Goals

• Changing the CLI itself (all changes are in the VS Code extension layer).
• Simultaneously operating on multiple app projects in a single command invocation.

---

Design Options

Option A: Extension Setting (winapp.appDirectories)

Add a VS Code setting that lists one or more relative paths to app project directories.

// .vscode/settings.json
{
  "winapp.appDirectories": [
    "apps/my-app",
    "apps/shell"
  ]
}

Behavior:

Scenario	What happens
Setting is absent or empty	Current behavior — use workspace root
Single entry	All commands auto-target that directory
Multiple entries	Quick Pick prompt: "Which app project?" before every command

Pros:

• Familiar VS Code pattern (workspace-level settings).
• Committed to .vscode/settings.json so the whole team benefits.
• Supports multi-root workspaces (each folder can have its own setting).

Cons:

• Requires manual configuration; not auto-discovered.
• Quick Pick on every command can be noisy for multi-app repos.

---

Option B: Auto-Detection (find winapp.yaml)

On activation (and on file-system watchers), scan the workspace for winapp.yaml files. Each discovered file's parent directory is a candidate app project.

Behavior:

Scenario	What happens
0 winapp.yaml found	Prompt user to run winapp init, using workspace root as default
1 winapp.yaml found	Auto-select that directory for all commands
N winapp.yaml found	Quick Pick prompt listing the discovered projects

Pros:

• Zero-config for the common case.
• Automatically adapts as projects are added/removed.

Cons:

• Only works after winapp init has been run (chicken-and-egg for the very first init).
• Could be slow in very large workspaces (mitigated by ignoring node_modules, .git, etc.).
• Doesn't let the user exclude directories they don't want to target.

---

Option C: Hybrid (Auto-Detection + Setting Override)

Recommended. Combine Options A and B:

1. Auto-detect winapp.yaml files in the workspace (with sensible ignore patterns).
2. Allow winapp.appDirectories setting to explicitly list or restrict project dirs.
3. If the setting is present, it takes precedence (no scanning).
4. If the setting is absent, fall back to auto-detection.

This gives zero-config convenience for most users while letting power users lock things down.

---

Open Questions

1. Should winapp init prompt for the target directory? Currently it always runs in the workspace root. For nested projects, the user likely wants to init in a subfolder. The extension could prompt "Initialize in workspace root or a subfolder?"

2. Should the auto-detection also look for Package.appxmanifest / appxmanifest.xml as fallback indicators? This would help pre-init scenarios where a manifest exists but winapp.yaml doesn't.

[chiaramooney]

• Think about solutions on a per-command basis. Maybe a different solution depending on which command is being run. Some commands are already taking a file path so they don't need this.
• Some commands need a csproj, manfiest, etc -- those commands should look for those files.