Conversation
Co-authored-by: Cursor <cursoragent@cursor.com>
|
Hey @LoganRupe let me know if you need any more info from me or any changes :) |
LoganRupe
left a comment
There was a problem hiding this comment.
Thanks, this is neat and small. Reusing readWorkspaceFile and the existing project.create path is what I'd have hoped for.
I gave it a spin against a dev desktop build and it works nicely. A .code-workspace with a couple of repos opens straight into a multi-root project, and a missing folder gets a clear warning instead of breaking anything. Plain directories still open exactly as before.
One small thing: the palette names a workspace project after the file (platform.code-workspace → "platform"), but this path uses inferProjectTitleFromPath(workspaceRoot). So a file sitting in ~/code gets titled "code". Could we pass the file-derived title through so both entry points agree?
Opening a .code-workspace with t3 app titled the project after the directory holding the file, which is often a generic parent such as ~/code. The command palette already titles it after the file, so share that rule in one helper and use it on both paths.
`t3 app` now accepts a .code-workspace file as well as a project directory. The CLI sends the file as workspaceFile and its parent as workspaceRoot; the desktop renderer resolves repoRoots through the existing filesystem.readWorkspaceFile query and creates the project the same way the command palette does. Workspace projects opened from the CLI are titled after the file, matching the palette.
`t3 app` now accepts a .code-workspace file as well as a project directory. The CLI sends the file as workspaceFile and its parent as workspaceRoot; the desktop renderer resolves repoRoots through the existing filesystem.readWorkspaceFile query and creates the project the same way the command palette does. Workspace projects opened from the CLI are titled after the file, matching the palette.
`t3 app` now accepts a .code-workspace file as well as a project directory. The CLI sends the file as workspaceFile and its parent as workspaceRoot; the desktop renderer resolves repoRoots through the existing filesystem.readWorkspaceFile query and creates the project the same way the command palette does. Workspace projects opened from the CLI are titled after the file, matching the palette.
`t3 app` now accepts a .code-workspace file as well as a project directory. The CLI sends the file as workspaceFile and its parent as workspaceRoot; the desktop renderer resolves repoRoots through the existing filesystem.readWorkspaceFile query and creates the project the same way the command palette does. Workspace projects opened from the CLI are titled after the file, matching the palette.
What Changed
t3 appnow accepts a.code-workspacefile as well as a project directory.The CLI treats that path as
workspaceFileand uses the file’s directory asworkspaceRoot. The desktop renderer reads the file with the existingfilesystem.readWorkspaceFilequery and passesworkspaceFile/repoRootsintoproject.create, the same path the command palette already uses. An existing project at that path is reused.Why
t3 apponly took a directory, so a multi-root workspace could not be opened from the terminal. The server storesworkspaceFileandrepoRootsas given, so the client has to resolve the file before create. That work already exists for the palette; this wires the same inputs through the CLI activation request instead of adding a second create path.