Repository navigation
fix(web,mobile): group No project across machines in settings - #25777
Jaiminp007 wants to merge 3 commits into
Conversation
Settings listed each machine's scratch folder as its own "No project" row. Group those folders in web and mobile settings, and open that shared group from a link that still names one scratch folder. Co-authored-by: Jaimin <Jaiminp007@users.noreply.github.com>
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Build grouped settings project snapshots apps/web/src/sidebarProjectGrouping.ts, apps/web/src/components/settings/useSettingsProjectGroups.ts, apps/mobile/src/features/settings/settings-environment-filter.tsx |
Web and mobile settings project groups enable scratch-project grouping. |
Resolve scratch project searches to settings groups apps/web/src/components/settings/settingsScope.ts, apps/web/src/components/settings/SettingsScopeContext.tsx, apps/web/src/environmentGrouping.test.ts |
The settings search resolver maps a scratch-project member key to an existing grouped project key. Scope resolution uses the mapped search, and tests cover merged scratch projects, a separate ordinary “No project” project, and search-key resolution. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix · Severity of issue fixed: Low
Possibly related issues
pingdotgg/t3code#22663— The changes cover scratch projects without repository identity, but the issue also includes ordinary non-repository folders.
Possibly related PRs
- pingdotgg/t3code#23531 — Changes shared project-grouping rules and scratch-scope resolution used by this change.
- pingdotgg/t3code#23894 — Also changes scratch-project grouping across environments.
Suggested reviewers: juliusmarminge, maria-rcks, macroscopeapp
Merge Risk: 
Minimal · up to 9b076
-
Scratch projects from multiple machines can appear as one settings group without losing their individual settings targets. No issue requiring resolution before merge was identified.
Pre-merge checks: 
4
-
Full details: Description check
-
Explanation
The description covers the problem, reproduction steps, implementation, scope and approval rationale, verification evidence, test results, limitations, and agent usage. It is complete and directly related to the pull request.
Full details: Linked Issues check
-
Explanation
Issue
#25571requires that "No project" scratch projects from different machines share one logical group key in Settings, not a key derived from a machine-specific path. The head implements this. In apps/web/src/sidebarProjectGrouping.ts, the new buildSettingsProjectSnapshots calls buildSidebarProjectSnapshots with groupScratchProjects: true. useSettingsProjectGroups.ts now calls this helper instead of buildSidebarProjectSnapshots, so web Settings groups scratch projects the same way the sidebar does. The mobile settings-environment-filter.tsx passes groupScratchProjects: true, which applies the same behavior to mobile Settings. The test in apps/web/src/environmentGrouping.test.ts ("groups No project across machines in settings") asserts one merged scratch group with the flag on and two groups with it off. Per the PR description, it also checks that a real project named "No project" stays separate. I did not run the test. The result relies on the author's report and the diff summary. The PR description says the author verified the web change with two local environments, not with a second physical machine. The mobile change was not tested on a device. These gaps do not change the code-level result for the requirement.
Full details: Out of Scope Changes check
-
Explanation
All changed files relate to the grouping requirement of
#25571or to its direct consequences. The sidebarProjectGrouping.ts and useSettingsProjectGroups.ts changes route Settings through the grouping helper with scratch grouping enabled. The mobile settings-environment-filter.tsx change applies the same flag to mobile Settings, which shows the same duplicate rows. Changing the group key would break existing per-machine scratch links, which would then resolve to "Unavailable project". The new resolveSettingsProjectSearch in settingsScope.ts and its use in SettingsScopeContext.tsx map those links to the shared group. The function only rewrites a project key when it is absent from the groups and resolution yields a different key that exists among the groups. This keeps a real project named "No project" unchanged when its key already exists. The test file covers the grouping, the separation of the real project, and link resolution. No unrelated feature or refactor appears in the reviewed summary. I did not inspect the import target@t3tools/client-runtime/state/project-groupingdirectly. My path guess did not resolve, and the PR summary lists no change to that package. This is a minor, unverified point and does not affect the verdict.
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
Problem
If you have more than one machine connected, the project picker in Settings shows a separate "No project" row for each machine. The sidebar already merges those into one "No project" group, so Settings should do the same.
To reproduce: connect two environments that each have a scratch thread, go to Settings > Threads, and open the "All projects" menu. You get one "No project" row per machine, e.g. "No project — DESKTOP-… " and "No project — MacBook Pro …".
Change
Settings builds its project groups with the same helper the sidebar uses, but it never turned on scratch grouping. This PR turns it on for web settings (
buildSettingsProjectSnapshots) and mobile settings (settings-environment-filter.tsx, same one-line omission).Because the grouped entry now has a single key, I also made settings resolve an older per-machine scratch link (from the sidebar or command palette) to the shared group, so those links don't land on "Unavailable project". A normal project that just happens to be named "No project" is left as its own group.
Scope and approval
Fixes #25571. The issue hasn't been triaged yet, but I think it counts as a small fix of an obvious bug: scratch grouping already exists and the sidebar already uses it, and Settings was just the one caller that left it off. Six files, no new behavior beyond matching the sidebar.
Verification
Before, on my own setup (Nightly, MacBook + Windows PC connected):
After, on this branch with two environments connected:
As a control, I flipped only the grouping flag off in the same session, and the two rows came back:
I added a test in
apps/web/src/environmentGrouping.test.ts("groups No project across machines in settings"). It fails with the flag off (two scratch groups) and passes with it on. It also checks that a real project named "No project" stays separate and that a per-machine scratch link resolves to the shared group.vp run check:changedpasses (format, lint, knip, typecheck, 20 tests).What I couldn't check: I ran the fixed build with two local environments on the Mac rather than against the PC itself, and I didn't test the mobile change on a device. The mobile change is the same one-line flag.
Done with help from a Cursor cloud agent (grok-4.7). I reviewed and tested the change myself.