Repository navigation
docs(api): regenerate reference to remove duplicate type names - #1332
Closed
mansiverma897993 wants to merge 1 commit into
Closed
mansiverma897993 wants to merge 1 commit into
mansiverma897993 wants to merge 1 commit into
Conversation
|
Important Review skippedToo many files! This PR contains 3000 files, which is 2900 over the limit of 100. To get a review, reduce the PR to 100 files or fewer by splitting it into smaller PRs or changing its base branch. Upgrade to a paid plan to raise the limit. Usage-priced reviews support at most 300 files. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3000)
You can disable this status message by setting the |
mansiverma897993
force-pushed
the
fix/1319-unique-type-names
branch
from
August 15, 2026 18:32
3a898b5 to
2ae7a9a
Compare
Contributor
|
Status update — this now needs a rebase before anything else matters, and the reason is not obvious from the checks page.
Two of those can never post on this branch as it stands. For
So those two required checks aren't pending — they will never appear, and the merge button stays disabled no matter what else you do. Only a rebase onto current Separately, the check that did run genuinely failed, and not for infrastructure reasons: Worth doing the rebase and the format fix in one pass, since the rebase will require a force-push regardless. One thing to flag honestly: at 3205 files this diff exceeded CodeRabbit's review limit, so no reviewer — human or bot — has actually looked at its contents. Given it's generated output that's probably acceptable, but it's worth someone confirming the generation was run against the right source rather than assuming. |
Fixes juspay#1319 (unique-type-names pattern analysis: 5 findings). The committed API reference was generated at v9.62 (May 9) and predates the type-rename that made setup/client type names globally unique (SetupOptions/SetupArgv/Config -> OpenAISetupOptions/AnthropicSetupOptions/...; BedrockTypes.Client/MistralTypes.Client -> BedrockClient/MistralClient). Because the docs were stale, they still documented namespace-scoped duplicate type aliases that collide after TypeDoc flattens them, and the pattern analysis flagged them as duplicate type names in cli.ts/providers.ts. Regenerating docs/api from the current source eliminates all five duplicates: - SetupOptions x6 -> 0 (now AnthropicSetupOptions, AzureSetupOptions, ...) - SetupArgv x6 -> 0 - Config x4 -> 0 (now *SetupConfig) - SetupArgs x3 -> 0 (namespaced ones are now HuggingFaceSetupArgs/MistralSetupArgs) - Client x2 -> 0 (now BedrockClient/MistralClient) No source code changes needed: src/lib/types/cli.ts and providers.ts already use globally unique prefixed type names (verified by the neurolink/unique-type-names ESLint rule). TypeDoc runs clean (0 errors). Regeneration command: pnpm run docs:api (typedoc).
mansiverma897993
force-pushed
the
fix/1319-unique-type-names
branch
from
August 21, 2026 04:24
2ae7a9a to
305a916
Compare
Contributor
Author
|
@murdore now check at once!! |
Contributor
|
I checked this by regenerating rather than by reading the diff — 70k lines of generated markdown isn't reviewable by eye, so the only question that matters is whether the committed output matches what the generator produces from current source. It doesn't, and the gap is large:
The good news is that the thing this PR set out to fix is now fixed for free. Issue #1319 is about duplicate type names, and a plain regeneration on current So the smallest correct change here is to regenerate on top of current git fetch origin release && git rebase origin/release
pnpm run docs:api # => typedoc
git add docs/api && git commit --amendThat keeps this PR as the one that closes #1319, and lands docs that match the code they document. Happy to do it if you'd rather not — say the word and I'll push the regeneration to this branch. Worth flagging separately, because it's the reason this PR aged badly rather than anything you did: nothing regenerates these docs. |
Contributor
|
Following up on my previous comment — I offered to push a regeneration to this branch and didn't hear back, and the staleness is a live defect on This is not a rejection of your work — it's the same change, and you got there first. Your PR reached 0 duplicates correctly; the only problem was that it was generated from a source tree that has since moved 3218 files, so merging it would have landed docs that were already out of date. If you'd rather keep this as the PR that closes #1319, say so and I'll close #1478 — all you need is: git fetch origin release && git rebase origin/release
pnpm run docs:api
npx prettier --write docs/api # required: docs/api isn't in .prettierignore,
# and raw typedoc output fails the format gate
git add docs/api && git commit --amendTwo things I learned doing it that are worth passing on:
Either way, #1319 gets closed. Just let me know which PR you'd like to carry it. |
Contributor
|
Closing as superseded: docs/api was regenerated from current source on release in f92be33, and the docs-drift CI gate now fails any PR that changes the API surface without regenerating — so the reference can no longer go stale the way it had. This branch's 3,206-file regeneration from an August 15 base can't rebase across that. Thanks for tackling it — the duplicate-type-name problem it targeted was real and got fixed at the source (unique-type-names lint rule) rather than in the generated output. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1319 -
unique-type-namespattern-analysis finding (5 duplicates).Root cause
The NeuroLink pattern analysis scans the committed API reference docs (
docs/api/, generated by TypeDoc). Those docs were last regenerated at v9.62 (May 9), but the type names were made globally unique in the Jul 29 commit (SetupOptions/SetupArgv/Config?OpenAISetupOptions/AnthropicSetupOptions/., andBedrockTypes.Client/MistralTypes.Client?BedrockClient/MistralClient).Because the committed docs were stale, they still documented the old namespace-scoped duplicate type aliases. TypeDoc flattens those into pages that collide, so the analyzer reported them as duplicate type names in
cli.ts/providers.ts:SetupOptionsAnthropicSetupOptions,AzureSetupOptions, .SetupArgvConfig*SetupConfigSetupArgsHuggingFaceSetupArgs/MistralSetupArgsClientBedrockTypes/MistralTypes)BedrockClient/MistralClientThe fix
Regenerated
docs/apifrom the current source withpnpm run docs:api(TypeDoc). No source-code changes were needed -src/lib/types/cli.tsandproviders.tsalready use globally unique prefixed type names, which theneurolink/unique-type-namesESLint rule confirms (0 violations onsrc/lib/types).Verification / test report
pnpm run docs:api(typedoc): 0 errors, 88 pre-existing doc warnings only.SetupOptions/SetupArgv/Config/Clienttype-alias pages: 0SetupArgstype-alias pages: 1 (the single legitimate top-levelSetupArgstype - not a duplicate)neurolink/unique-type-namesESLint rule onsrc/lib/types: 0 violations (source was already unique).tsc --noEmit --strict: clean for the changed files.This is a docs-only change; no runtime/test behavior is affected.
Update: Rebased onto the current
elease\ head (v10.12.9, incl. the merged #1304) and docs re-generated from it - the PR remains a single docs-only commit, mergeable. All five \unique-type-names\ findings remain resolved (verified: 0 duplicate type-alias pages).