fix: include monorepo root dependencies in project_index dependency_locations#1902
fix: include monorepo root dependencies in project_index dependency_locations#1902BlackStar1453 wants to merge 2 commits intoAndyMik90:developfrom
Conversation
In packaged Electron apps, console.log writes to a pipe/PTY whose buffer can fill up, causing the synchronous write() syscall to block the main thread indefinitely. This was observed as a 66-second UI freeze on 2026-02-25 (macOS hang report). Setting console transport level to false in production eliminates the blocking write path entirely. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
ProjectAnalyzer._find_and_analyze_services() iterates subdirectories of service_locations but never analyzes the project root itself as a service. In monorepo projects where the root has package.json + node_modules (e.g., npm/pnpm workspaces), these root-level dependencies are completely missed, causing dependency_locations to be empty for the largest dependency directory (~1GB node_modules). This causes worktrees to either fail to create symlinks or have agents run npm install, duplicating the full node_modules per worktree. After the monorepo service discovery loop, check if the project root has dependency-bearing files (package.json, requirements.txt, pyproject.toml) and analyze it as a "root" service if it contributes dependency_locations. This ensures root-level node_modules gets included and properly symlinked into worktrees. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
|
|
Summary of ChangesHello @BlackStar1453, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses two distinct issues: one related to backend dependency analysis in monorepos and another concerning frontend logging performance. The primary goal is to enhance the accuracy of dependency tracking for monorepo root projects and to improve application stability by optimizing console logging behavior in production builds. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🎉 Thanks for your first PR!
A maintainer will review it soon. Please make sure:
- Your branch is synced with
develop - CI checks pass
- You've followed our contribution guide
Welcome to the Auto Claude community!
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request addresses an issue where dependencies in a monorepo's root were not being detected. The fix introduces a check for root-level dependencies after scanning for services in subdirectories, which correctly identifies and includes them in the project index. This is a good improvement for monorepo support. I've added one suggestion to improve code maintainability by extracting a hardcoded list of files into a constant. The other change in app-logger.ts to disable console logging in production is also a good performance fix.
| Path(s.get("path", "")) for s in services.values() | ||
| } | ||
| if not already_covered: | ||
| dep_indicators = ("package.json", "requirements.txt", "pyproject.toml") |
There was a problem hiding this comment.
This tuple of dependency indicator files is hardcoded. For better maintainability and clarity, consider defining this as a named constant at the module level, for example ROOT_DEPENDENCY_FILES. This makes the purpose of this list explicit and easier to update in the future.
📝 WalkthroughWalkthroughAdds logic to analyze root-level dependencies in monorepo projects when the root contains dependency indicators and no service already covers it, ensuring root-level dependencies are included in analysis results. Also disables console logging in production builds to prevent potential stdio buffering issues. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/backend/analysis/analyzers/project_analyzer_module.py`:
- Around line 123-136: The check for already_covered should compare
normalized/resolved paths and the insertion of a synthetic root should not
clobber a real service named "root"; modify the logic that builds
already_covered to use Path(...).resolve() (or .absolute()) for each
s.get("path") and self.project_dir.resolve(), and before assigning
services["root"] ensure you do not overwrite an existing key (e.g., skip if
"root" in services or choose a non-colliding key), and keep the existing
creation flow that uses ServiceAnalyzer(self.project_dir, "root") and
root_info.get("dependency_locations") to populate the synthetic root only when
safe.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
apps/backend/analysis/analyzers/project_analyzer_module.pyapps/frontend/src/main/app-logger.ts
| already_covered = self.project_dir in { | ||
| Path(s.get("path", "")) for s in services.values() | ||
| } | ||
| if not already_covered: | ||
| dep_indicators = ("package.json", "requirements.txt", "pyproject.toml") | ||
| root_has_deps = any( | ||
| (self.project_dir / f).exists() for f in dep_indicators | ||
| ) | ||
| if root_has_deps: | ||
| root_analyzer = ServiceAnalyzer(self.project_dir, "root") | ||
| root_info = root_analyzer.analyze() | ||
| root_deps = root_info.get("dependency_locations", []) | ||
| if root_deps: | ||
| services["root"] = root_info |
There was a problem hiding this comment.
Avoid overwriting a real root service and harden root coverage detection.
Line 136 unconditionally writes services["root"], which can clobber an actual discovered service named root. Also, Line 123-Line 125 compares non-normalized paths, which can mis-detect already_covered and trigger unintended insertion.
Proposed fix
- already_covered = self.project_dir in {
- Path(s.get("path", "")) for s in services.values()
- }
+ discovered_paths: set[Path] = set()
+ for service in services.values():
+ raw_path = service.get("path")
+ if not raw_path:
+ continue
+ discovered_paths.add(Path(raw_path).resolve())
+ already_covered = self.project_dir in discovered_paths
if not already_covered:
dep_indicators = ("package.json", "requirements.txt", "pyproject.toml")
root_has_deps = any(
(self.project_dir / f).exists() for f in dep_indicators
)
if root_has_deps:
root_analyzer = ServiceAnalyzer(self.project_dir, "root")
root_info = root_analyzer.analyze()
root_deps = root_info.get("dependency_locations", [])
if root_deps:
- services["root"] = root_info
+ root_key = "root" if "root" not in services else "project_root"
+ services[root_key] = root_info🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/backend/analysis/analyzers/project_analyzer_module.py` around lines 123
- 136, The check for already_covered should compare normalized/resolved paths
and the insertion of a synthetic root should not clobber a real service named
"root"; modify the logic that builds already_covered to use Path(...).resolve()
(or .absolute()) for each s.get("path") and self.project_dir.resolve(), and
before assigning services["root"] ensure you do not overwrite an existing key
(e.g., skip if "root" in services or choose a non-colliding key), and keep the
existing creation flow that uses ServiceAnalyzer(self.project_dir, "root") and
root_info.get("dependency_locations") to populate the synthetic root only when
safe.
3 participants
Base Branch
developbranch (required for all feature/fix PRs)main(hotfix only - maintainers)Description
ProjectAnalyzer._find_and_analyze_services()iterates subdirectories ofservice_locationsto discover services but never analyzes the project root itself. In monorepo projects where the root haspackage.json+node_modules(npm/pnpm workspaces pattern), the root-levelnode_modules(~1GB) is completely missed fromdependency_locations, causing worktrees to duplicate the fullnode_modulesinstead of symlinking it.This fix adds a root-level dependency check after the monorepo service discovery loop. If the project root has dependency-bearing files and contributes
dependency_locations, it's included as a"root"service.Related Issue
Closes #1901
Type of Change
Area
AI Disclosure
Tool(s) used: Claude Code (Claude Opus 4.6)
Testing level:
Untested -- AI output not yet verified
Lightly tested -- ran the app / spot-checked key paths
Fully tested -- all tests pass, manually verified behavior
I understand what this PR does and how the underlying code works
What Changed
Single file:
apps/backend/analysis/analyzers/project_analyzer_module.py(+18 lines)After the existing monorepo service discovery loop (which finds
apps/frontend,apps/backend, etc.), added a check for root-level dependencies:package.json,requirements.txt,pyproject.toml)ServiceAnalyzeron the root and includes it if it hasdependency_locationsBefore:
dependency_locationsinproject_index.jsonwas missing rootnode_modules[ {"type": "node_modules", "path": "apps/frontend/node_modules", "service": "frontend"}, {"type": "venv", "path": "apps/backend/.venv", "service": "backend"} ]After:
[ {"type": "node_modules", "path": "apps/frontend/node_modules", "service": "frontend"}, {"type": "venv", "path": "apps/backend/.venv", "service": "backend"}, {"type": "node_modules", "path": "node_modules", "service": "root", "package_manager": "npm"} ]Verification
Ran the analyzer on the Auto-Claude project itself and confirmed root
node_modulesnow appears independency_locations. The existing_aggregate_dependency_locations()method already handles root paths correctly (Path(".") / "node_modules"→"node_modules").Checklist
developbranchPlatform Testing Checklist
platform/module instead of directprocess.platformchecksfindExecutable()or platform abstractions)CI/Testing Requirements
Feature Toggle
Breaking Changes
Breaking: No
The change only adds previously-missing data to
dependency_locations. All consumers already handle arbitrary entries in this list, so no downstream changes are needed.Summary by CodeRabbit