You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
A VSCode workspace may contain multiple sourcekit-lsp workspaces. To be specific, by "VSCode workspace" I mean the folder you are opening in a VSCode window and by "sourcekit-lsp workspace" I mean the workspaces managed by sourcekit-lsp (which effectively tells the LSP server where to search for Package.swift or compile_commands.json). As I understand it, this VSCode extension automatically tries to find a workspace when a Swift file is opened in the VSCode UI, and there is no way to influence this behavior. The one customization option provided is "search subfolders for packages", which tries to identify workspaces when the extension starts up.
This is fine for most projects, but there are times when this is problematic. One example is a project with a top-level Package.swift file (the "user-facing package") may have a number of other packages in its directory tree (packages testing the user-facing package, local packages that can be referenced by the user-facing package, or just one-off examples). I've noticed a number of weird issues in such a project, including some failures with package resolution (which can be disabled via an option) and LSP functionality being unavailable for the nested packages.
Describe the solution you'd like
For my example above, just deleting the top-level Package.swift fixed all my issues (i.e. LSP began working well in the nested packages). It would be great if there was a setting like the following:
Note that in this case a workspace located at "the/workspace/I/care/about" would still be enabled even though it is nested under ".", which is excluded. Support for "*" would be nice for folders of test projects.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
A VSCode workspace may contain multiple sourcekit-lsp workspaces. To be specific, by "VSCode workspace" I mean the folder you are opening in a VSCode window and by "sourcekit-lsp workspace" I mean the workspaces managed by sourcekit-lsp (which effectively tells the LSP server where to search for Package.swift or compile_commands.json). As I understand it, this VSCode extension automatically tries to find a workspace when a Swift file is opened in the VSCode UI, and there is no way to influence this behavior. The one customization option provided is "search subfolders for packages", which tries to identify workspaces when the extension starts up.
This is fine for most projects, but there are times when this is problematic. One example is a project with a top-level Package.swift file (the "user-facing package") may have a number of other packages in its directory tree (packages testing the user-facing package, local packages that can be referenced by the user-facing package, or just one-off examples). I've noticed a number of weird issues in such a project, including some failures with package resolution (which can be disabled via an option) and LSP functionality being unavailable for the nested packages.
Describe the solution you'd like
For my example above, just deleting the top-level Package.swift fixed all my issues (i.e. LSP began working well in the nested packages). It would be great if there was a setting like the following:
Note that in this case a workspace located at "the/workspace/I/care/about" would still be enabled even though it is nested under ".", which is excluded. Support for "*" would be nice for folders of test projects.
The text was updated successfully, but these errors were encountered: