refactor: modularize providerRegistry.ts (Issue #3594)

[oyi77]

Summary

This PR addresses the high-priority massive file open-sse/config/providerRegistry.ts (4,676 lines) as part of the WordPress-style Plugin System modularization effort tracked in #3594.

Changes

• Extracted types, shared constants, and dependencies into open-sse/config/providers/shared.ts.
• Split the monolithic REGISTRY object into 5 alphabetical domain chunks:
  • a-c.ts
  • d-h.ts
  • i-o.ts
  • p-s.ts
  • t-z.ts
• Assembled the registry in open-sse/config/providers/index.ts and re-exported it from providerRegistry.ts to maintain full backward compatibility for existing imports.

Verification

• npm run typecheck:core passes.
• npx eslint open-sse/config/providers/* has 0 errors/warnings.
• No production behavior changes, strictly structural.

Resolves part of #3594.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[oyi77]

Update: Addressed architectural feedback!

The previous alphabetical grouping (a-c.ts, d-h.ts, etc.) was indeed an anti-pattern for a true WordPress-style plugin system.

I have completely refactored the extraction to establish a strict One-File-Per-Provider architecture. There are now exactly 159 individual provider files inside open-sse/config/providers/registry/.

This means when we add a new provider in the future, it's just a matter of dropping a new standalone .ts file into that directory, and the index.ts handles the rest.

Typechecking and linting both pass cleanly.

[oyi77]

Update 2: Sub-categorization and DRY Headers!

As requested, I've further refined the one-file-per-provider structure.

1. Sub-Categorization: Highly-related provider variants are now grouped into dedicated sub-directories. For example:

   • minimax and minimax-cn → registry/minimax/default.ts and registry/minimax/cn.ts
   • glm, glm-cn, glmt → registry/glm/default.ts, registry/glm/cn.ts, registry/glm/t.ts
   • opencode, opencode-go, opencode-zen → registry/opencode/default.ts, etc.
     This keeps the top-level registry/ folder clean and organized while maintaining the strictly modular 1-file-per-variant rule.

2. DRY Helpers: I scanned the 159 extracted files for duplicated logic and extracted them into reusable helpers inside shared.ts:

   • getClaudeCliHeaders() for the massive 14-line Claude CLI header block shared by agentrouter and claude.
   • getAnthropicCompatHeaders() for the recurring Anthropic-Version headers in providers like minimax, minimax-cn, zai, and bailian-coding-plan.
   • buildAntigravityUrl() for the repeating streaming/non-streaming logic shared between agy and antigravity.

All tests, typings, and ESLint checks pass locally. This sets up a flawless foundation for the plugin system!

[oyi77]

Update 3: True Folder-as-Module Refactor!

As an ultimate refinement to the plugin architecture, I've refactored all 159 individual provider files into the folder-as-module pattern.

Now, every single provider lives in its own dedicated directory with an index.ts file.
For example:

• registry/openai/index.ts
• registry/anthropic/index.ts

And the variants elegantly nest inside their parent's folder:

• registry/minimax/index.ts (default)
• registry/minimax/cn/index.ts (variant)
• registry/opencode/index.ts (default)
• registry/opencode/go/index.ts (variant)

This provides exactly the foundation needed for a WordPress-style plugin system. When a provider gets complex, it can now have local utils.ts, types.ts, or tests/ co-located directly inside its own folder without polluting the global scope!

All tests and linting verified 100% green.

[diegosouzapw]

Thanks @oyi77 for the modularization work on open-sse/config/providerRegistry.ts (Issue #3594). I can't merge this as it currently stands — and the reason is structural, not about the quality of the split:

1. It's a stacked/cumulative chain. This branch carries ~49–55 commits all starting from chore(release): open v3.8.23 development cycle, and the per-PR additions grow monotonically (refactor: modularize providerRegistry.ts (Issue #3594) #3617 ≈ +22k → refactor: modularize 3.1K-line providers.ts constants (Issue #3594) #3646 ≈ +52k). Each refactor branch is built on top of the previous one, so merging any single PR drags in all the earlier refactors too. That makes each PR impossible to review in isolation and guarantees conflicts between them.

2. The base is stale (v3.8.23 era). Since these were cut, release/v3.8.24 has merged dozens of PRs — including changes to the very files several of these PRs modularize (e.g. providerRegistry.ts grew via fix(providers): correct Ollama Cloud kimi-k2.7-code capabilities (#3761) #3768, validation.ts via fix(providers): repair qwen-web validation + stop mislabeling benign redirects as SSRF (#3288, #3758) #3767, plus combo/stream/usage edits). GitHub now reports this PR as CONFLICTING, and the conflicts are substantial.

What would let this land: re-cut it as a single, independent PR branched from the current release/v3.8.24 tip, modularizing only open-sse/config/providerRegistry.ts (not stacked on the other refactors), small enough to review on its own. One file per PR, rebased on current release. I'll gladly review and merge them in that form — the god-file modularization goal is worth it; it's the 14-deep stack on a 2-week-old base that can't go in. Leaving this open so nothing is lost.

[oyi77]

Closed in favor of clean re-cut — see #3793 (providerRegistry), #3798 (combo), #3797 (validation), #3796 (imageGeneration), #3795 (usage), #3794 (providers). Only modularization commits were cherry-picked onto current release/v3.8.24 — no stacked dependencies, no unrelated changes.