feat(yeoman-ui): implement generator progress notifications

[korotkovao]

Summary

Implements improved generator progress notifications per internal issue 38263.

Key improvements:

• Display project name in notification title: "Generating {projectName}"
• Show progress updates through three distinct phases:
  • "Creating project files..."
  • "Installing dependencies..."
  • "Finalising..."
• Include project name in success message: "Project {projectName} has been generated."
• Use continuous indeterminate spinner (not stuck progress bar)
• UK English spelling ("Finalising" not "Finalizing")

Technical details:

• Added doGeneratorProgress method to track generator lifecycle events
• Listens to yeoman generator events: method:writing, method:install, method:end
• Changed doGeneratorDone return type from void to Thenable<any> to properly return the result of showDoneMessage
• Added artificial 2s delay for writing phase to ensure UI visibility
• Extracts project name from multiple generator state locations for compatibility
• Stubbed WorkspaceFile.createWsWithPath and createWsWithUri in tests to prevent filesystem writes in CI

Test coverage:

• Added 12 new comprehensive tests for doGeneratorProgress and project name display
• Updated existing tests to handle async doGeneratorDone and stub WorkspaceFile methods
• All 283 tests passing (265 in CI before fixes, now all passing)
• Lint validation passing

[alex-gilin]

Code Review: PR #576 — feat(yeoman-ui): implement generator progress notifications

Overview

The PR replaces the single "Installing dependencies..." notification with a phased progress notification driven by yeoman lifecycle events (method:writing, method:install, method:end). It adds a project name to the title (Generating {projectName}) and success message, keeps one long-lived withProgress notification alive via a stored progressReporter, and updates doGeneratorDone to return a Thenable so the caller can await the done message. It also hardens tests against real filesystem writes.

The user-facing goal is reasonable and the test additions are welcome. However, there are a few correctness concerns worth resolving before merge.

🔴 Significant Issues

1. Phase messages can render out of order (race between fixed delays)

vscode-youi-events.ts:144-155

Each yeoman event handler calls void doGeneratorProgress(...) without awaiting (yeomanui.ts:598-613), so three independent async calls run concurrently, each with its own setTimeout:

• install reports after await 2000ms + 10ms
• end reports after 10ms

For a fast/no-op install, method:end fires shortly after method:install, so the end handler reports "Finalising…" first, and ~2s later the install handler overwrites it with "Installing dependencies…" — the reverse of the intended sequence. The artificial 2s delay is decoupled from actual progress and is the root cause. Consider sequencing the phases (await the chain) or driving the message purely from the latest event rather than fixed timers.

2. Early doClose() on method:writing likely breaks the "closed manually" analytics

vscode-youi-events.ts:138-140 → AbstractWebviewPanel.ts:133-156

The writing phase now calls doClose(), disposing the webview panel. method:writing fires for essentially every generator, whereas the old doGeneratorInstall() only closed the panel for generators that had an install step.

doClose() → panel onDidDispose → AbstractWebviewPanel.dispose(), which reads GENERATOR_COMPLETED. That flag is only set later in doGeneratorDone (vscode-youi-events.ts:107) — and by then this.webviewPanel is already null, so set(null, …) is a no-op. Net effect: on normal completion the panel is disposed during writing with GENERATOR_COMPLETED === undefined, so dispose() treats it as a manual close and fires updateGeneratorClosedManually for successful generations. Please verify this on a generator without an install step — I believe it's a telemetry regression.

3. Non-VSCode (WebSocket) path invokes an RPC with no frontend handler

server-youi-events.ts:48-54

ServerYouiEvents.doGeneratorProgress calls this.rpc.invoke("generatorProgress", …), but App.vue's initRpc function list (App.vue:665-679) has no generatorProgress handler (confirmed by grep — none exists in frontend/). This await will reject/hang for the standalone browser flow. Either add the frontend handler or guard the invocation.

🟡 Moderate Issues

4. doGeneratorInstall appears to be dead code now

onGenInstall no longer calls doGeneratorInstall — it calls doGeneratorProgress for all phases. The only remaining references to doGeneratorInstall are its interface/impl definitions and a test (youi-events.ts:11, vscode-youi-events.ts:119). If it's genuinely unused, remove it (and its test); otherwise document who still calls it.

5. User-facing strings bypass the i18n messages.ts convention

vscode-youi-events.ts:129-133, 392, 399-403

The codebase centralizes strings in messages.ts (artifact_generated_*, etc.). The new strings ("Creating project files…", "Installing dependencies…", "Finalising…", "Generating {name}", "Project {name} has been generated.") are hardcoded inline. This is inconsistent with the existing pattern the PR is otherwise using (this.messages.*) and makes future localization harder. Move them to messages.ts.

6. Fragile timing assumptions

vscode-youi-events.ts:142-143

The 50ms sleep "wait for the progress reporter to be initialized" assumes vscode.window.withProgress's callback runs within 50ms. This is a race; if the reporter isn't set in time, the install report silently no-ops. A promise that resolves when progressReporter is assigned would be deterministic.

🟢 Minor / Style

• Loose typing: progressReporter: any and initialMessage-style comments. VS Code's Progress<{ message?: string; increment?: number }> is the proper type; using it would catch report-shape mistakes (vscode-youi-events.ts:65).
• Duplicated "Finalising…": reported both in doGeneratorDone (line 103) and the end phase (line 132). Given the ordering issue in #1, consider a single source of truth.
• getProjectName heuristics: the 6-way _.get fallback chain (yeomanui.ts:586-595) is pragmatic but undocumented — a brief comment on why these specific paths exist would help maintainers.
• getSuccessInfoMessage duplication: the project-name and fallback branches are near-identical mirrors (vscode-youi-events.ts:395-417). Could collapse by computing the workspace suffix once.

Tests

• Good additions for doGeneratorProgress phases, project-name titles, and success messages, plus the WorkspaceFile stubbing to prevent CI filesystem writes.
• Concern: the install phase test exercises the real await 2000ms, adding ~2s of wall-clock per run. Consider injecting/faking the delay (e.g., sinon fake timers) so the suite stays fast.
• Gap: none of the new tests cover the phase ordering (issue #1) or the early-doClose analytics behavior (issue #2) — the two areas most likely to break. The tests assert each phase in isolation, which is why the ordering bug slips through.

Summary

The feature direction is sound and test coverage is expanded, but I'd hold merge on the three 🔴 items — particularly the out-of-order phase messages (#1) and the early-dispose analytics regression (#2), both of which affect the normal success path for most generators. The i18n and dead-code cleanups (#4, #5) are worth folding in while touching this code.

[korotkovao]

Thank you for the review @alex-gilin I have updated to address your changes

[alex-gilin]

Overview

The author (with Anton Gula) pushed 33 commits addressing the earlier review findings. The feature is now opt-in, gated behind both a VS Code setting (ApplicationWizard.showGeneratorProgress, default
true) and a per-generator flag (gen.options.showGeneratorProgress, default false — only Fiori opts in). This significantly narrows the blast radius and is the right approach: non-opted-in generators
are unaffected.

Status of previous findings

• [1] — Out-of-order phase messages (race): FIXED. The fixed 2s delay was replaced with elapsed-based minimum-duration scheduling. Verified by reproduction: order now holds (writing → installing →
  finalising) even in the fast/no-op install case that broke the old code.
• [2] — Early doClose() breaks GENERATOR_COMPLETED analytics: PARTIALLY ADDRESSED. The new guard only prevents calling doClose() twice; the writing phase still disposes the webview before
  doGeneratorDone sets the flag. This can fire a false updateGeneratorClosedManually telemetry event. Mitigated by opt-in gating (Fiori only) and by the fact the old code already disposed early on
  method:install, so it isn't strictly new. Note: the added test "sets GENERATOR_COMPLETED flag before disposal" only checks ordering within doGeneratorDone — it does NOT exercise the writing-phase
  early dispose, so it gives false confidence on this scenario.
• [3] — Missing frontend generatorProgress RPC handler: FIXED. Added to App.vue, registered in initRpc, dead generatorInstall removed, WebSocket path guarded by showProgress.
• [4] — Dead doGeneratorInstall: MOSTLY FIXED. Removed from interface and both implementations. Leftover no-op doGeneratorInstall() stubs remain in the two TestEvents classes (yeomanui.spec.ts,
  youi-adapter.spec.ts) — harmless dead code worth deleting.
• [5] — Hardcoded strings / i18n: PARTIALLY ADDRESSED. Progress phase strings are now in messages.ts (progress_*) and consumed in vscode-youi-events. But the success messages in getSuccessInfoMessage,
  the "Generating {name}" title, and the frontend App.vue phase strings remain hardcoded English.
• [6] — Fragile 50ms/10ms timing hacks: FIXED. Those setTimeouts were removed.

New issues introduced (out of original scope)

• activationEvents: ["*"] — eager activation regression. package.json changed [] → ["*"], forcing the extension to activate on every VS Code startup for all users. This is a startup-performance
  anti-pattern unrelated to this feature and looks like a debugging leftover. Please revert unless deliberate.
• version: "1.27.0-local" — local artifact committed. Versioning is handled by changesets; the -local suffix should be reverted.
• autoOpenApplicationInfoPage setting. Adds a VS Code setting whose implementation lives in a different repo (per the commit message), so it's a no-op setting here. Unrelated to progress notifications
  — split into its own PR.

generator-foodq example

The PR adds a dietary-preferences questionnaire to the foodq example generator (~90 lines). This is unrelated to the progress-notifications feature and inflates the diff.

Importantly, foodq already has everything needed to demonstrate the feature — it has real writing(), install() (a genuine npmInstall), and end() lifecycle methods, which are exactly what drive
method:writing / method:install / method:end. The only thing missing to showcase progress notifications is the opt-in flag.

Recommendation:

• Revert the dietary-preferences questionnaire.
• Instead, add the opt-in in the constructor: this.option("showGeneratorProgress", { type: Boolean, default: true }); — this makes foodq exercise the feature end-to-end (and its real npmInstall makes
  the "Installing dependencies…" phase genuinely visible).
• Remove or annotate the existing this.appWizard.showProgress("Generating the FoodQ project.") call in writing(), since it competes with the new notification and would show two overlapping progress
  UIs.

Minor

• Instant-install UX: when install is a no-op, install and end are scheduled to fire on the same tick, so "Installing dependencies…" can flash and be immediately overwritten. Fine for Fiori (real npm
  install), but worth noting.
• Frontend generatorProgress sets isDone = true on every phase, flipping to the "done" view during generation. Mirrors the old generatorInstall behavior, so acceptable; phase strings there are
  duplicated/hardcoded rather than localized.
• Instance state not reset: currentPhase / phaseStartTime / currentProjectName persist on the VSCodeYouiEvents instance across runs. Low risk given lifecycle, but a second generation could observe
  stale values.
• Slow test: "phases fire in correct order…" uses a real await setTimeout(3500) (adds 3.5s to the suite) and manually sets progressReporter/currentPhase, so it doesn't fully exercise the event-driven
  path. Consider fake timers.

Verdict

The core review issues are resolved and the opt-in gating is a strong risk mitigation. I'd block merge only on the two clearly-accidental package.json changes (activationEvents: ["*"] and version:
"1.27.0-local"), and recommend splitting out the unrelated autoOpenApplicationInfoPage setting and reworking the foodq example to actually demonstrate the feature (opt-in flag) rather than the dietary
survey. The residual analytics concern [2] is lower severity given opt-in plus pre-existing behavior, but the test that claims to cover it doesn't — worth a quick manual check on Fiori before
shipping.