LGTM! ✅

🗣️ Give feedback

I dug into why sync-rspec.ts existed on master, and I do not think this PR is functionally equivalent yet for local developer workflows.

Historical context first.

The TypeScript sync-rspec.ts tooling was introduced in PR #6492 (commit c164606ee45891c9174946437d97db99a5b325e3). The point of that change was not just to move logic around. It was added specifically to replace the rspec-maven-plugin path because the Maven flow was not robust enough for day-to-day development:

• it depended on sonar-rule-api auth behavior that required GITHUB_TOKEN in the environment;
• it was not as straightforward to run on developer machines as the existing Node-based workflow;
• SonarJS wanted the generated rule-data that feeds JS/TS builds to be reproducible locally with the normal repo tooling, without special Maven/plugin auth setup.

That history matters here, because the bar for removing sync-rspec.ts is not only “the build passes in CI” or “the generated files look mostly the same”. The replacement also needs to preserve the developer ergonomics we had on master: on a clean machine/worktree, a developer should be able to regenerate the RSPEC-derived outputs with the normal build flow as easily as before.

I tested that explicitly.

On this branch, using a clean worktree, npm ci + npm run bbf does regenerate the expected outputs, and the repository shape is aligned with the intended direction:

• RSPEC JSON/HTML and rspec.sha are generated at build time and are not git-tracked;
• generated-meta.ts files are generated at build time and are not git-tracked;
• generated Java check classes are generated at build time and are not git-tracked.

So the repository-layout goal is mostly correct.

However, there is still one important regression compared to master: if I delete the generated RSPEC outputs in a clean worktree and run the generation flow without exporting GITHUB_TOKEN, the Maven path fails. In practice that means the replacement is still not as easy to run on dev machines as the sync-rspec.ts flow it is removing.

The reason is upstream:

1. rspec-maven-plugin still does not accept any explicit GitHub auth parameter. The plugin currently only exposes ruleSubdirectory, targetDirectory, and vcsBranchName, and then constructs GitHubRuleMaker.create(branch) internally.
2. The released plugin version used here (1.3.0.46) depends on sonar-rule-api 2.18.0.5734, where GitHubRuleMaker only looks at System.getenv(GITHUB_TOKEN).
3. Even on current sonar-rule-api master, while GitHubRuleMaker now falls back to gh auth token, CoverageLoader still hard-requires GITHUB_TOKEN from the environment.

So even if SonarJS switches back to the Maven-based generation flow, we are still missing the pieces needed to make that flow dev-machine-friendly in the same way master was.

For me, the minimum bar for functional equivalence is:

• a clean checkout/worktree can regenerate the RSPEC-derived outputs without requiring contributors to pre-export GITHUB_TOKEN in their shell;
• the build can use existing developer auth state (for example gh auth login) or an explicit parameter, instead of only ambient environment variables;
• the generated HTML/JSON output matches the current TypeScript flow closely enough that we do not introduce content regressions.

Concretely, I think this means the upstream work is still required before SonarJS can safely remove sync-rspec.ts:

1. In sonar-rule-api, introduce a shared token resolution mechanism used everywhere GitHub access happens.
   Precedence should be something like: explicit token parameter -> GITHUB_TOKEN env var -> gh auth token.
2. In sonar-rule-api, expose APIs that allow callers to pass the token explicitly instead of forcing env lookup internally (for example GitHubRuleMaker.create(branch, token) and a corresponding CoverageLoader constructor/entry point).
3. In rspec-maven-plugin, expose an optional auth parameter (or Maven settings-based credential lookup) and pass it explicitly to sonar-rule-api.
4. After that, SonarJS can bump to the new plugin/rule-api versions and keep this PR’s general repository policy: generated RSPEC outputs, generated TS meta, and generated Java checks should all be build-time artifacts and not be tracked in git.

There is also one output-level issue worth addressing before we treat the Maven flow as a drop-in replacement: I found a real HTML rendering delta on S7724.html where the generated output contains stray <strong> markup around the phrase after /* eslint-disable */. The JSON differences I saw were only ordering/newline noise, but this HTML difference looks substantive.

So my conclusion is:

• the repository cleanup direction in this PR is good;
• but the TypeScript sync-rspec.ts tooling was originally added for a concrete developer-workflow reason, not just implementation preference;
• and we have not fully closed that gap yet, because the Maven path still depends on GITHUB_TOKEN being exported in the environment in scenarios where master was easier to use.

I would be comfortable with this switch once the Maven/plugin/rule-api stack is updated so that local generation works smoothly on developer machines without requiring manual env-token setup, and once the HTML rendering delta is understood/fixed.