Revert "feat(monorepo): implement orchestrator"

[ovflowd]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
api-docs-tooling	Ready	Preview	Apr 23, 2026 2:54pm

[cursor]

PR Summary

Medium Risk
Refactors the generator orchestration/config/threading pipeline to use a centralized, lazily-loaded generator registry keyed by short names; mistakes here could break doc generation or worker execution across many generators. Changes are mostly mechanical but touch core execution paths and CI artifacts/naming.

Overview
Switches generator selection from package specifiers to short generator names across the CLI, CI workflow, and scripts, and restricts generate -t/--target to known public generator choices.

Replaces dynamic generator graph loading with a centralized registry (publicGenerators/allGenerators) and a new createLazyGenerator pattern: each generator’s index.mjs now exports metadata only, while implementations move to generate.mjs and are imported lazily.

Updates core orchestration, config, and worker threading to reference generators by name (removing loader.mjs), derive default config from the registry, and run processChunk in workers via generatorName. Adds/updates tests to validate generator metadata, lazy loading behavior, and the new worker invocation style.

^{Reviewed by Cursor Bugbot for commit 28b2300. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 45.03632% with 908 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (feature/monorepo@6def80a). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...kages/core/src/generators/legacy-html/generate.mjs	0.00%	140 Missing ⚠️
...ages/core/src/generators/addon-verify/generate.mjs	0.00%	82 Missing ⚠️
...s/core/src/generators/legacy-json-all/generate.mjs	0.00%	80 Missing ⚠️
packages/core/src/generators/man-page/generate.mjs	0.00%	78 Missing ⚠️
...s/core/src/generators/legacy-html-all/generate.mjs	0.00%	75 Missing ⚠️
packages/core/src/generators/jsx-ast/generate.mjs	0.00%	70 Missing ⚠️
...kages/core/src/generators/legacy-json/generate.mjs	0.00%	66 Missing ⚠️
packages/core/src/generators/sitemap/generate.mjs	0.00%	66 Missing ⚠️
packages/core/src/generators/orama-db/generate.mjs	0.00%	60 Missing ⚠️
packages/core/src/generators/web/generate.mjs	0.00%	54 Missing ⚠️
... and 9 more

Additional details and impacted files

@@                 Coverage Diff                 @@
##             feature/monorepo     #779   +/-   ##
===================================================
  Coverage                    ?   75.78%           
===================================================
  Files                       ?      156           
  Lines                       ?    13877           
  Branches                    ?     1093           
===================================================
  Hits                        ?    10516           
  Misses                      ?     3356           
  Partials                    ?        5           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[avivkeller]

I disagree with reverting this. The original PR followed all guidelines, and is a feature branch, one which iterations can continue to appear on.

Reverting it has no practical effect, IMO, and undoes valuable work on the next stages of the monorepo.

WDYT @nodejs/web-infra

[MattIPv4]

👍 Yes, I was just talking with Claudio about this, I agree that you followed the correct process, the PR was open for three weeks before landing, and was merged a week after an approval was given. Folks had plenty of time to object prior to it landing. And yes, this is a feature branch, not main, so we can continue to just iterate instead of flip-flopping with reverts.

[MattIPv4]

If y'all want to use the politics of our contribution guidelines in bad faith, I'll also act in bad faith.

I don't believe Aviv, nor I, are using guidelines in bad faith -- the PR was absolutely landed in good faith with an approval and plenty of time given for folks to review.

I do not think it is appropriate for you to then express anger at Aviv in the PR when it landed, after you decided not to block it or review it in the three weeks that it was open. Nor do I feel it is appropriate for you to then declare you are going to intentionally act in bad faith and disrupt the project by blocking further work.

[avivkeller]

Alrighty, I will be the jackass one, but I'll block the PR from ever getting merged to main from this feature branch.

This is not a constructive way to engage, and it runs contrary to the Node.js Code of Conduct. I'd ask that you reconsider this position. Blocking a PR as a form of protest isn't an appropriate use of review authority.

It will be extremely exhausting iterating on the changes #731 originally introduced and would probably be dismissed. I don't understand why being adamant on having said changes merged on the feature branch, instead of properly going through them. Either way is extra work, either way is ensuring that the codebase follows standards that everyone is happy with.

I'd like to clarify the process here. The PR was open for an appropriate review window, and reviews were submitted and addressed during that time. If you had concerns with the changes, the time to raise them was while the PR was open, so reverting now is redundant.

If y'all want to use the politics of our contribution guidelines in bad faith, I'll also act in bad faith. I find it heartless that #731 got merged as is, even if open for 3 weeks, without getting proper reviews. This isn't the way and it's bending the guidelines in your favor.

No one here is acting in bad faith. Following the contribution guidelines as written is not bending them; openly stating you'll act in bad faith in response, however, is a serious problem. The PR was open for three weeks, which is more than reasonable opportunity for review. The absence of your review during that window is not the same as the PR lacking review, and it isn't grounds to retaliate now.

[avivkeller]

I am not expressing anger at Aviv, just at the PR. I sincerely doubt any ill intent was done from Aviv, as I said in my opener, I do believe they followed all the guidelines, although I personally don't think the PR should have been merged as is.

You very much are expressing anger at me, and other members of the web team.

We are all volunteers here, and I, personally, will not tolerate these blatant attacks on my contributions, and my character.

I'd really like if @nodejs/moderation stepped in to de-escalate this situation.

[flakey5]

We can simply ask to @flakey5 if his approval was a rubberstamp approval or if he actually went through the code in detail and is in agreement with all the changes

It was not a rubberstamp approval nor a "blank" review.

I'd like to echo what @avivkeller has said in how this thread is not even remotely constructive or abiding by the Code of Conduct and heavily suggest everyone take a breather. It's just a feature branch.

[bmuenzenmeyer]

I'd really like if @nodejs/moderation stepped in to de-escalate this situation.

I've alerted the team (and as a member of both, am recusing myself from weighing in too forcefully, but agree that we should remove ill-intent from the conversation)

[jasnell]

@nodejs/tsc ... heads up.

[ovflowd]

FYI that I deleted my comments as feeling them being inappropriate, but anyone with admin access can check the history/audit.