refactor(schema): drop the declarations nothing has ever read - #562
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe change removes ChangesAI edition schema removal
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This maintenance-only change removes unused AI edition schemas without changing supported behavior or user-facing functionality. Reported checks pass, so it is ready to merge. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
`addAssetInputSchema.autoTranscribe` was declared with a `true` default and consumed by nobody: one occurrence in the whole tree, its own declaration. That is worse than clutter. It reads like the switch that decides whether an imported asset gets transcribed, so the next person to work on transcription finds it, believes the decision already has a home, and wires their logic to a flag no code path consults. It surfaced during the design of #560 for exactly that reason. The field goes; the schema keeps its shape otherwise. Nothing type-checks against it — `document-service.ts` declares its own `AddAssetInput` interface and uses that one, so the inferred type this schema exports was not in play either.
`addAssetInputSchema` and `chatInputSchema` had no reference anywhere outside their own declaration and their own `z.infer` line — no parse site, no import, no namespace import of the module. They named an IPC contract that no boundary actually validates against. `addAssetInputSchema` was the worse of the two: the `AddAssetInput` it exported is shadowed by a same-named interface declared in `document-service.ts`, and that interface is the one every caller uses. Two types, one name, and the one that looked canonical was inert. `createProjectInputSchema` STAYS. It reads as dead by the same grep — no use outside `schema/index.ts` — but its inferred `CreateProjectInput` types `createEmptyDocument`, which has 50 call sites. Same file, one line down; the reference is easy to miss and expensive to remove.
|
Rebased on main. The conflict was worth a note: since this PR opened, It still has zero consumers — That is precisely the trap this PR describes: the schema looks like the place where "how an imported asset is handled" is declared, so the next person to touch the subject wires their work to it. Deleting it now, |
01f69d4 to
756bfc4
Compare
Summary
Three removals in
schema/index.ts, all of them declarations nothing ever read.addAssetInputSchema.autoTranscribe— declared with atruedefault, one occurrence in the whole tree: its own line. Worse than clutter, because it reads like the switch that decides whether an imported asset gets transcribed. The next person working on transcription finds it, believes the decision already has a home, and wires their logic to a flag no code path consults. It surfaced while designing #560, which needs somewhere to express "transcribe only what can carry speech" — and this looked like it.addAssetInputSchemaitself, and theAddAssetInputit exported. No parse site, no import, no namespace import of the module. It named an IPC contract that no boundary validates against. It was also actively confusing:document-service.tsdeclares a same-namedAddAssetInputinterface (line 38) and that is the one every caller uses. Two types, one name, and the one that looked canonical was inert.chatInputSchemaand itsChatInput— same story, no shadowing twist.What is NOT removed, and why it looked removable
createProjectInputSchemastays. It reads as dead by exactly the same grep — zero references outsideschema/index.ts— but its inferredCreateProjectInputtypescreateEmptyDocument, which has 50 call sites. The reference is one line below the type export, inside the same file, and is easy to miss.Worth stating rather than quietly keeping: "no references outside its own module" is not a liveness test for a type that a function in that module consumes.
Related issue
Refs #560 — found while pinning down where automatic transcription should be decided.
Type of change
Release impact
Desktop impact
Screenshots / video
None — no user-visible change.
Testing
npm run test— 2236 passed, 4 skipped, 0 failed (187 files)npx tsc --noEmitandnpx tsc -p tsconfig.test.json --noEmit— cleannpm run lint(Biome) — clean (15 pre-existing warnings in untouched files)No test asserted on any of the removed declarations, so none needed changing. The typecheck is the real proof here: had any of the three been reachable, both
tscpasses would say so.🤖 Generated with Claude Code
Summary by CodeRabbit