Use the CLI for runnable-project classification once it exposes a query API

クローズ
  • 何か問題がありますか？
#273 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 11 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
cli, developer-experience, tooling

調査の方向性

Wait for the upstream CLI query API, then start with src/project-detection.ts and the run-target flow in src/run-target.ts and src/run-utils.ts. Run src/test/project-runnability.test.ts and update coverage for CLI discovery, fallback behavior, and auto-selection. Done means the extension prefers supported CLI results while retaining the current fallback for older bundled CLI versions.

索引モデルが issue の本文から書いたものです。

説明

enhancement

Context

The run-target picker (WinApp: Run Application, Run Application (Advanced), and the F5 fallback) lists projects and solutions discovered across the workspace. To keep class libraries and test projects out of that list, src/project-detection.ts classifies each project file with a small static parse:

  • <IsTestProject>true</IsTestProject> → test
  • a Microsoft.NET.Test.Sdk PackageReference → test
  • explicit <OutputType>Library</OutputType> → library
  • anything else, including a missing OutputType → unknown, and therefore still offered

This is deliberately one-sided and fails open (filterOfferableProjects returns the unfiltered list if filtering would remove every candidate), and the extension defers the real decision to the CLI: --project is only passed when two or more candidates survive, otherwise nothing is passed and winapp run resolves it.

Why this is a placeholder

winapp run already classifies authoritatively via full MSBuild evaluation, but exposes no way to query that result without building and launching. Filed upstream as microsoft/winappCli#957.

A static parse cannot see an OutputType that comes from an SDK default, Directory.Build.props, or a condition. When it disagrees with the CLI, the extension can narrow to a single candidate, skip the disambiguation prompt, pass no --project, and the run then fails with the CLI's ambiguity error. That error is clear and now surfaces in the WinApp output channel behind Show Output, so it is recoverable — but a correct list would avoid it.

What to do when the upstream API lands

  1. Prefer the CLI's discovery output (for example winapp run <input> --list-projects --json) when the bundled CLI supports it.
  2. Fall back to the current static heuristic when it does not — the extension currently downloads latest, so it must tolerate both (see #250).
  3. Use the CLI's reported auto-selection to decide whether to prompt at all, replacing the local "prompt only when ≥2 candidates" rule.
  4. Drop or reduce classifyProjectRunnability / readProjectRunnability / isOfferableProject once the fallback is no longer needed.

Not worth doing

Parsing the candidate list out of winapp run's ambiguity message on stderr. It is an emoji-decorated, potentially localized console string, and it costs a failed run on every ambiguous launch.

Pointers

  • src/project-detection.ts — classifyProjectRunnability, readProjectRunnability, isOfferableProject
  • src/run-target.ts — filterOfferableProjects, filterOfferableCandidates
  • src/run-utils.ts — pickRunTarget, pickSolutionProject
  • src/test/project-runnability.test.ts — classification tests, including the fail-open rule
主要言語
TypeScript
スター
15
フォーク
4
平均マージ
10日 10時間
マージ済み PR（30日）
9

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/WinAppVSCE のほかの issue

microsoft/WinAppVSCE の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。