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

test: add a black-box architecture violation and repair proof

クローズ
#35 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
49/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
javascript, node.js, playwright, react, typescript, vite

調査の方向性

Read the existing unit and integration tests, generator entry point, public CLI commands, and CI workflows to see how the project creates and validates a clean JST project. Build the proof in a temporary project, covering the two named violation families and asserting their stable diagnostic codes, reasons, repairs, and documentation links. Run npm run check and npm run test:e2e; done means the repaired project passes npm run validate and the proof cleans up temporary output on both success and failure.

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

説明

enhancement help wanted javascript

Problem

JST has unit and integration coverage for individual rules, generators, SSR, and browser behavior, but it lacks one black-box proof of the complete user loop:

clean project
→ canonical generated slice
→ real architecture violation
→ actionable failure
→ repair
→ green project

Without this contract, a rule, generator, documentation example, or normal validation command can remain green independently while the promised end-to-end repair path is broken.

Scope

Add an executable proof that works against a temporary clean project and uses the same public commands documented for users.

The proof must:

  1. create a temporary clean JST project;
  2. run the real slice generator;
  3. verify the generated project is initially green;
  4. introduce a private cross-slice import violation;
  5. introduce an external-effect-in-view violation;
  6. run the normal validation command and assert actionable diagnostics;
  7. apply the documented repairs;
  8. verify the project returns to green.

Acceptance criteria

  • The proof invokes public CLI/generator entry points rather than imported test-only internals.
  • It verifies at least two independent violation families.
  • The negative phase exits non-zero for the expected stable diagnostic codes.
  • Diagnostics include a reason, repair, and stable documentation link.
  • The repaired project passes npm run validate.
  • Temporary output is removed after both success and failure.
  • The proof performs no network access after dependencies are installed.
  • It runs on Linux, macOS, and Windows in CI.
  • Failure artifacts contain the command log and final diff, but not node_modules.
  • The user-facing proof command completes within five minutes on the supported CI runners.
  • npm run check and npm run test:e2e remain green.

Dependency

Blocked by jst-stack/eslint-plugin#8. Do not bind this proof to complete human-readable error strings.

Design constraints

  • Keep the harness outside application layers.
  • Do not add production exports for the test.
  • Keep fixtures minimal: they exist to prove the repair loop, not to become another showcase.

Out of scope

  • Marketing copy, video, or GIF production.
  • Artificially weakening the policy to simplify the demonstration.
  • Testing every JST diagnostic; the conformance corpus owns exhaustive coverage.

Validation

npm ci
npm run check
npx playwright install chromium
npm run test:e2e
主要言語
JavaScript
スター
1
フォーク
0
平均マージ
12時間 37分
マージ済み PR(30日)
23

環境構築

はじめの一歩

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

似ている issue

JavaScript の issue をもっと見る

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

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