Add support for workspace #1238
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR adds workspace support by introducing a new Workspace structure and integrating workspace-related operations into project and LSP services. Key changes include updating the Workspace API (adding SetRoot, AddFolder, and RemoveFolder), refactoring OpenFile calls to remove redundant parameters, and adapting tests and server logic to work with the new workspace management.
Reviewed Changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| internal/project/workspace.go | Introduces Workspace struct with helper functions for folder management. |
| internal/project/workspace_test.go | Adds tests validating GetProjectRootPath and folder addition/removal in a workspace context. |
| internal/project/service.go and related tests | Updates OpenFile signature and usage to derive project root path from Workspace instead of a parameter. |
| internal/lsp/server.go | Integrates workspace updates in LSP initialization and folder change notifications. |
| Others (service_test.go, projectreferencesprogram_test.go, etc.) | Adjust tests to accommodate removal of the redundant projectRootPath parameter in OpenFile calls. |
Comments suppressed due to low confidence (1)
internal/lsp/server.go:646
- The handler uses 's.workspace' for updating workspace folders, but elsewhere workspace operations are performed through 's.projectService.Workspace'. To ensure consistency and avoid potential nil pointer issues, consider using 's.projectService.Workspace' or ensuring 's.workspace' is properly initialized.
s.workspace.AddFolder(ls.DocumentURIToFileName(lsproto.DocumentUri(folder.Uri)))
| } | ||
| if s.initializeParams.WorkspaceFolders != nil { | ||
| for _, folder := range s.initializeParams.WorkspaceFolders.Value { | ||
| s.projectService.Workspace.AddFolder(ls.DocumentURIToFileName(lsproto.DocumentUri(folder.Uri))) |
There was a problem hiding this comment.
Do you know why we need to handle this kind of thing? Typically this stuff is only ever used if we plan to explicitly handle multi-root workspaces, but I don't think we have a reason to do that, since we're great at just accepting whatever gets opened anyway?
There was a problem hiding this comment.
this was used for creating better inferred projects - thats when projectRootPath was introduced
It is also used to not lookup tsconfig beyond the project root locations. I added this because with multi project thing the search locations increase and wanted to make sure i am not going beyond the point it needs to.
No description provided.