Repository navigation
Conversation
![opencodejr[bot]](https://avatars.githubusercontent.com/in/5497873?s=60&v=4){kind=small}
There was a problem hiding this comment.
The fix works. I ran the PR's version of e2e/regression/home.spec.ts against both checkouts. On the base, a client with no usage history shows no projects on Home. With this PR it lists the server's projects, and both changed cases pass. The one other failing case in that file ("interface mode") fails on the base too. Unit tests in src/runtime/server pass, and typecheck:tsc is clean.
Public API: unchanged. The only addition is a new client-side storage key, hiddenProjectIDs, which is backwards compatible: existing stored data decodes with an empty default.
Concerns:
- Design reversal. 7aac8f7 deliberately made Home list only the projects this client has used, with Close to hide one. The rest of the server's projects were left to the new-session location dialog, Settings and the command palette. This PR turns Home into "every server project minus local hides". That is a product decision maintainers need to confirm. It is also what #13626 asks for.
- Upgrade effect. Close on current
devonly removed a project from the used list. Nothing was stored as hidden, so every project a user closed before will reappear after upgrading (details inline). Every project the server has registered will also show, including stray ones like the home folder or drive root from #49428. - Inconsistent lists. The new-session location dialog (
new-session/project/controller.ts) and Settings (settings/workspaces/projects.tsx,project-options.tsx) still split projects into used ones and "Other projects" usingprojects.used(). Projects that are now listed on Home will still show up as "other" there. If Home's definition changes, those places should follow, or the reason they differ should be explicit.
| list, | ||
| unique, | ||
| // Server history is shared across clients; only an explicit local hide excludes a project. | ||
| visible: createMemo(() => { |
There was a problem hiding this comment.
Only IDs in hiddenProjectIDs exclude a project, but that list starts empty for everyone upgrading. On current dev, hide() only removed IDs from usedProjectIDs, so every project a user closed before will reappear on Home after upgrading, and so will projects that were never in their legacy directory list. The e2e expectation in the migration case changed to include docs for this reason. Also, because hiding is by project ID, a hidden folder comes back if the server later registers it under a new ID (the multiple-IDs-per-path case touch() already handles). If this direction is accepted, consider how to treat existing clients, e.g. seeding hidden IDs from the server projects that aren't in usedProjectIDs on first load, or hiding by path rather than by ID.
There was a problem hiding this comment.
The new push only merges dev into the branch. The PR's own changes are unchanged, so the open point about upgrading clients is still open, and the design questions from my earlier review still stand. I re-ran the changed Home e2e cases, the src/runtime/server unit tests and typecheck:tsc on the new head, and all pass. One e2e case failed on the first run, which cold-started the dev server, and passed when re-run on its own. Public API: unchanged. The only addition is the client-side storage key hiddenProjectIDs, which is backwards compatible.
Issue for this PR
Closes #60565
Related: #13626; overlaps the project-list portion of #53752.
Type of change
What does this PR do?
Home omits server projects absent from this client's usage history. List the server's active projects and track explicit local hides separately, preserving Close/reopen and legacy migration. Reopening a path restores all of its historical project IDs.
How did you verify your code works?
bun run checkand appbun run typecheck:tscpass.Visual
Screenshots / recordings
Before and after, with the same server inventory and empty client usage history:
Checklist
Added by the opencode bot (AI-generated).
Fixes #13626
Related: #49428