fix: read the workspaces key from wmill.yaml

[rubenfiszel]

Reported by a customer: after moving their wmill.yaml to the new workspaces key, the extension stopped picking up their workspace, logging No gitBranches configuration found in wmill.yaml and staying on whichever workspace the CLI had active.

workspaces:
  cm:
    baseUrl: https://windmill.pagtech.net/
    gitBranch: main
    workspaceId: cm

The bug

The extension read exactly one key, config["gitBranches"], and looked the branch up as a map key. Both are wrong against today's CLI (cli/src/core/conf.ts):

• Key name — the primary key is workspaces; gitBranches / environments / git_branches are deprecated aliases the CLI normalizes in readConfigFile. The extension only knew the first alias, so the config was invisible.
• Lookup — in the new format the key is the workspace name; the branch is entry.gitBranch ?? name. Even via the legacy key, config["main"] would have missed an entry named cm.
• workspaceId now defaults to the workspace name (getEffectiveWorkspaceId); the extension required it explicitly.
• Remote comparison normalized only the config side, so a remote entered without a trailing slash never matched.

I verified the published 0.2.60 build has the same code — the exact string the customer saw is in the shipped bundle, so nothing was lost in an unreleased change.

Also in here

Fork branches. On wm-fork/<base>/<id> the CLI targets the fork workspace wm-fork-<id>, resolved from the branch name; wmill.yaml is consulted only for the base branch's entry, which supplies the remote, and auth is reused from that workspace's profile. The CLI never persists a fork profile (it derives one in memory per command, core/context.ts), so there's nothing for syncVSCodeConfigFromCLI to pull in — the extension registers a derived entry itself, named <parent>/wm-fork-<id>, re-added after each sync since additionalWorkspaces is rewritten wholesale.

Ambiguous profiles. When several profiles share a remote and workspace id — the same workspace as different identities — the extension silently took the first. It now reads the choice the CLI remembered in branch-profiles.json. It deliberately does not prompt when there's no remembered choice: this runs from the .git/HEAD watcher and on activation, so a QuickPick would appear because you ran git checkout. It falls back to the first match and names it in the notification; Windmill: Switch workspace remains for choosing deliberately.

Stale config. The workspaces config was only reloaded when the active editor changed, so editing wmill.yaml had no effect until you switched files — plausibly the next thing to hit anyone who has just corrected that file. Now watched.

findCodebase returned undefined at the first codebase that didn't match, making every codebase after the first unreachable. The CLI's own findCodebase continues the loop; this now does too. Found while covering the module — the regression test fails against the previous behaviour.

Testing

161 tests (from 46). tsc --noEmit clean, npm run lint 0 errors with no new warnings, and both bundles build (esbuild node + webpack web).

Statement coverage of the touched modules went from 73% to 99% (100% functions, 95% branches):

module	statements	branches
config/config-manager.ts	100%	100%
config/branch-profiles.ts	100%	87%
utils/git-utils.ts	100%	100%
workspace/workspace-manager.ts	99%	92%

Git detection and config loading go through the vscode filesystem API rather than node's, so the test stub grew an in-memory filesystem, open-document set and workspace folders. syncVSCodeConfigFromCLI does use node fs, so it runs against a real temporary config dir laid out the way the CLI writes it — no fs mocking needed.

Covered: config key precedence across all three deprecated aliases; branch matching via gitBranch and via the name; switchWorkspaceForBranch end to end (profile match/non-match, workspaceId defaulting, trailing-slash and unparseable-URL normalization, missing baseUrl, already-on-target no-op, synthetic main, failed settings write); the fork cases (derived entry contents, re-registration after a sync wipe, parent token rotation, unconfigured base branch, malformed fork branch not falling through to the parent); the ambiguity cases (remembered choice honored, configFolder passed through, fallbacks, fork inheriting the chosen identity's token); .git/HEAD parsing including worktree gitdir indirection both absolute and relative, detached HEAD, and unreadable HEAD; the root-first wmill.yaml search and its precedence, plus unsaved editor buffers winning over disk; the CLI sync and its failure modes; checkAndSwitchWorkspaceForGitBranch including a wmill.yaml that isn't valid YAML; the web-environment guards that keep the webpack build from touching node fs; and the status bar.

The branch-profiles.json location (<configDir>/0/, from the CLI's getStore("")) is exercised against a real file written in the CLI's layout, and was additionally verified against the actual file the CLI wrote on my machine.

Three defects the tests caught and I fixed rather than shipped: the two fork-branch helpers disagreed on wm-fork/main/ (empty id), which would have silently targeted the parent workspace — they now derive from one parser; a failed CLI-config read aborted the whole switch through the outer catch, now best-effort; and the findCodebase scan above.

Uncovered by design: workspace-manager.ts:233-234, a "no workspace folder" guard only reachable after getCurrentGitBranch already succeeded — which itself requires a workspace folder; and the default-config-dir branch of getLastUsedProfile, which would read the developer's real ~/.config/windmill.

🤖 Generated with Claude Code