Repository navigation
Split first-party screenshot requirement scan out of the migration collector - #1656
Conversation
…llector ThirdPartyToolMigrationFastAssemblyRequirementCollector mixed two independent, field-free scanning concerns in one 622-line file: general assembly-reference requirement collection and first-party screenshot API requirement collection. Neither section referenced the other and both were entirely stateless, so this was pure responsibility mixing rather than a single cohesive algorithm. Move CollectFastFirstPartyScreenshotRequirementsAsync and its private helpers (source-level scan, three legacy-detection predicates, and the FirstPartyScreenshotRequirementScan DTO) into a new ThirdPartyToolMigrationFastFirstPartyScreenshotRequirementCollector. The sole caller, ThirdPartyToolMigrationTargetScanner, used `using static` for both entry points, so it now imports the new class alongside the original. Register the new file's async ct-parameter method in StaticFacadeStateGuardTests' tracked path list.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
💤 Files with no reviewable changes (1)
📝 WalkthroughWalkthroughThe first-party screenshot fast-requirement collection logic was removed from ChangesScreenshot requirement collector extraction
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Scanner as ThirdPartyToolMigrationTargetScanner
participant Collector as ThirdPartyToolMigrationFastFirstPartyScreenshotRequirementCollector
participant Source as SourceFile
Scanner->>Collector: CollectFastFirstPartyScreenshotRequirementsAsync(filePaths)
loop for each source file
Collector->>Source: read file text
Collector->>Collector: filter migration-candidate text
Collector->>Collector: resolve nearest assembly directory
Collector->>Collector: run FirstPartyScreenshotRequirementScan
alt HasMigrationTarget true
Collector-->>Scanner: return true
end
end
Collector-->>Scanner: return false
Possibly related PRs
🚥 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 |
Refs: R3-10 in the Unity CLI Loop Phase 3 refactor ToDo
Summary
ThirdPartyToolMigrationFastAssemblyRequirementCollector.cs(622 lines) mixed two independent, field-free scanning concerns: general assembly-reference requirement collection and first-party screenshot API requirement collection. Neither section referenced the other (zero shared state, zero cross-calls), so this was genuine responsibility mixing rather than a single cohesive algorithm — confirmed by grep before implementing.CollectFastFirstPartyScreenshotRequirementsAsyncand its private helpers (CollectFastFirstPartyScreenshotRequirementsForSource,ScanFastFirstPartyScreenshotRequirement, three legacy-detection predicates, and theFirstPartyScreenshotRequirementScanDTO struct) into a newThirdPartyToolMigrationFastFirstPartyScreenshotRequirementCollector.ThirdPartyToolMigrationTargetScanner, usedusing staticfor both entry points, so it now imports the new class alongside the original (documented adaptation in the normalized diff).internal, everything else staysprivate.Background: is the migration path still needed?
Confirmed active — recent commits during this same refactor series (
8cd2402e,071fd76c,2f77d180) continue investing in the migration subsystem, and it has ~10k lines of dedicated tests (ThirdPartyToolMigrationFileServiceTests.cs+ThirdPartyToolMigrationRulesTests.cs). Not a winding-down feature, so this pure-move investment is warranted (per the ToDo's own decision tree).Verification
sort -u+comm -23/comm -13) across the collector + new file + caller shows an empty "removed" set and only 3 added lines (new class doc-comment, new class declaration, newusing staticimport in the caller) — a clean pure move.uloop compile— 0 errors / 0 warnings.ThirdPartyToolMigration*test suite — 364/364 pass (4 pre-existing skips), 0 failures.StaticFacadeStateGuardTests— 20/20 pass (new file registered in the async ct-parameter guard list; the moved async method already used the standardctparameter name, no rename needed).Test plan
uloop compilecleanThirdPartyToolMigration*tests 364/364 passStaticFacadeStateGuardTests20/20 pass