Group Make targets (and other command types) with a consistent visual language
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 38/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Ruhig
- Tech-Stack
- typescript
- Bereich
- developer-experience, tooling
Rechercherichtung
Start with src/CommandTreeProvider.ts and its buildRootCategories() entry point, then inspect the providers under src/discovery/. Review src/discovery/make.ts for the variable-filtering requirement and trace how each provider currently builds its command list. Done means a shared TaskGroup classifier and consistent grouping across the listed providers, with the specified Make, VS Code, Mise, and end-to-end fixture behavior.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Problem
The tree currently shows a flat list of Make targets under Make Targets (13) — help, build, ci, clean, fmt, lint, package, setup, test, test-exclude-ci, plus variables like COVERAGE_THRESHOLDS_FILE and UNAME that leaked in as pseudo-targets. This doesn't scale: real Makefiles routinely have dozens of targets and users can't find what they need.
The same problem exists across every command-type we support (Mise tasks, VS Code tasks, npm scripts, Just recipes, etc.). Each provider currently shows a flat list, and there is no shared visual language for grouping.
Goal
A consistent grouping visual language across all command types — Make, Mise, VS Code tasks, npm, Just, Cargo, Gradle, Rake, Taskfile, etc. — so that a user who learns the grouping for one provider immediately understands the others.
GNU convention (source of truth for Make)
Per GNU Makefile Conventions — Standard Targets for Users, standard target names fall into natural groups:
| Group | Standard targets |
|---|---|
| Build | all (default) |
| Install | install, install-html, install-pdf, install-ps, install-strip, installdirs, installcheck, uninstall |
| Clean | clean, mostlyclean, distclean, maintainer-clean |
| Test | check |
| Docs | info, html, pdf, ps, TAGS |
| Dist | dist |
These are the canonical groups a user expects. Our grouping must at minimum recognise these.
Proposed groups (cross-provider)
A single taxonomy used by every discovery provider:
- Build — compile/package (Make
all/build, npmbuild, Cargobuild, VS Codebuildgroup, Misebuild:*) - Test — Make
check/test, npmtest,pytest, Cargotest, VS Codetestgroup - Lint / Format —
lint,fmt,format,check-format - Run / Dev —
start,dev,serve,watch, launch configs - Clean —
clean,distclean,mostlyclean,maintainer-clean - Install / Deps —
install,setup,bootstrap,uninstall,install-* - Release / Dist —
dist,package,release,publish - CI —
ci,ci-* - Docs —
docs,html,pdf,info,ps - Other — anything unmatched
Classification strategy
- Name-prefix / name-suffix rules —
test-*,*-test,docker-*,db-*group by prefix. - Known-target dictionary — exact matches to GNU standard names and common ecosystem names (npm's
start/test/build; Cargo'sbuild/test/check/doc; Misebuild:*/test:*). - Provider-native metadata where available:
- VS Code tasks:
groupfield (build,test) — see tasks.json reference. - npm: lifecycle scripts (
pre*/post*) are grouped under their parent. - Mise:
:namespace (build:web,build:api) — group by the prefix before:. - Just: doc comments above recipes.
- Make: parse
## group: <name>or## commentannotations when present (popularmake helpconvention).
- VS Code tasks:
- Fallback: ungrouped targets go to Other.
Visual language
- Each group shown as a collapsible tree node with a consistent icon + label across providers.
- e.g. "Build" always uses the same icon whether it comes from Make, npm, or VS Code tasks.
- Group order is fixed across providers (Build → Test → Lint → Run → Clean → Install → Release → CI → Docs → Other).
- Groups with zero matches are hidden.
- Single-item groups still render (consistency beats compactness).
- A setting
commandtree.groupingwith valuesauto(default) /flat/customlets users opt out.
Out of scope (follow-ups)
- User-configurable custom groups via
commandtree.json. - Per-workspace overrides of the default classification dictionary.
- Drag-to-regroup in the tree.
Acceptance
- Shared
TaskGroupenum + classifier module used by every discovery provider - GNU standard Make target names classify correctly (see table above)
- VS Code tasks honour their native
groupfield - Mise
:namespaces become groups - Variables like
COVERAGE_THRESHOLDS_FILEandUNAMEno longer appear as Make "targets" (separate filtering fix in src/discovery/make.ts) - E2E test asserts that, given a fixture Makefile with
all,clean,distclean,check,install, they land in Build / Clean / Clean / Test / Install respectively - E2E test asserts grouping is identical in structure for a fixture
package.json,Justfile, andmise.tomlwith equivalent tasks
References
- GNU Makefile Conventions
- GNU Standard Targets for Users
- VS Code task groups
- src/CommandTreeProvider.ts —
buildRootCategories() - src/discovery/ — 20+ providers that all need the shared classifier
- Vorherrschende Sprache
- TypeScript
- Sterne
- 3
- Forks
- 2
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus Nimblesite/CommandTree
-
enhancement priority: critical security
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
Nimblesite/CommandTree#24 ·
Alle Issues in Nimblesite/CommandTree
Ähnliche Issues
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 85/100
MystenLabs/MemWal#1163 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Mondriaan
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
knaw-huc/textannoviz#709 ·
Maintainer antworten meist innerhalb von 1 Tag
-
billion-context-pi
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
ranxianglei/billion-context#2521 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Add: YRF Music NepalOffenstreams:add
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 62/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100