Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#35 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
49/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, node.js, playwright, react, typescript, vite

Research direction

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.

Written by the indexing model from the issue text.

Description

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
Dominant language
JavaScript
Stars
1
Forks
0
Avg merge
1d 3h
Merged PRs (30d)
11

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from jst-stack/jst

All issues in jst-stack/jst

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.