Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

usabl init: support monorepos and non-root app directories

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
typescript, vite
領域
testing-qa, tooling

調査の方向性

Start by reading the usabl init discovery code and the Vite and router lookup paths; the issue names platform/vite.config.ts, framework/vite.config.ts, and the runtime route assembly in platform/main/PlatformRoutes.tsx. Reproduce the empty draft on a monorepo, then check how discovery reports missing routes and empty uiFileGlobs. Done means init produces a usable draft for a named workspace or explains why it refuses and gives the manual next step, while preserving the single-app path.

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

説明

area: setup enhancement

usabl init assumes a single application at the repository root. On a monorepo it finds neither the Vite config nor the router, writes an empty draft, and leaves the whole config to be hand-authored.

Found while dogfooding on a real second project (#110): ansible/ansible-ui at devel, a PatternFly 6.3.1 monorepo.

What happened

$ usabl init
Wrote usabl.config.json, usabl.routes.json.
Review: no Vite config found; using http://127.0.0.1:5173.
Review: no router file found. Routes sidecar will be empty.
Review: these files are drafts. Merge only after you check routes, globs, and URLs.

The drafts came out with uiFileGlobs: [], surfaces: [], and routes: []. A config in that state resolves to nothing to check, so the gate reports idle on every change.

Why it happened

Two separate assumptions, both reasonable for a single-app repo and both wrong here.

  1. Vite config lookup is root-only. This repo's config is at platform/vite.config.ts, and there is a second one at framework/vite.config.ts. init looked at the root, found nothing, and fell back to the default port. The real dev server runs on 4100 over https, not 5173 over http, so the fallback URL is wrong in three ways at once.

  2. Router discovery expects a static route file. This repo composes routes at runtime from hooks (platform/routes/useGetPlatform*Routes.tsx, assembled in platform/main/PlatformRoutes.tsx), and the path values are relative fragments joined into a tree. There is no file a static reader can parse into absolute URLs.

What it got right

It refused to guess. Every failed inference printed a Review: line naming what it could not determine, and it wrote empty collections rather than inventing routes. A wrong route map would have been worse than a missing one, and the honesty invariant held. This issue is about reach, not about correctness.

Proposed direction

Not a design decision yet, just the options as they look from here.

  • Detect nested Vite configs and, when more than one is found, refuse and print the candidates for the operator to choose rather than picking one.
  • Read the resolved dev server port and protocol from the chosen Vite config instead of assuming the default, since server.port and https are both set explicitly here.
  • Accept an operator-supplied application subdirectory, so usabl init --app platform scopes discovery to one workspace.
  • When routes cannot be derived statically, say so explicitly and point at the manual surface mapping path, rather than writing an empty sidecar that silently reads as idle.
  • Consider whether an empty uiFileGlobs should be a refusal rather than a draft, since the resulting config cannot ever produce a verdict.

Acceptance

  • usabl init on a monorepo either produces a usable draft for a named workspace or refuses with the reason and the manual next step.
  • A config that can never produce a verdict is not written silently.
  • The existing single-app path is unchanged.
主要言語
TypeScript
スター
0
フォーク
0
平均マージ
2時間 48分
マージ済み PR（30日）
8

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

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

usabl-dev/usabl のほかの issue

usabl-dev/usabl の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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