Is your feature request related to a problem? Please describe.
As a core developer, it's very easy for me to create a mixed mode workspace and hit actively unsupported behavior as noted in lightning-lsp-common/src/shared.ts. When I do these behaviors, the LWC extension doesn't load and I don't get its benefits.
When I include a test/func or test/unit project in my partial build.
When I include a submodule in my partial build, like the common logging one. (exact name redacted in this public issue tracker)
My workspace (and every core dev's workspaces) is generated based on local partial build config, so it's easy to hit one of these traps.
Describe the solution you'd like
Enhance the detection in shared.ts to return WorkspaceType.CORE_PARTIAL appropriately for workspaces generated by our internal build tools. I think this would be a really simple change actually. The workspace detection just needs to look up 1-5 parent directories for a "workspace-user.xml" instead of lookup up just a single parent directory.
Describe alternatives you've considered
While developing PR #558, I strategically deleted parts of my generated code-workspace file, and then launched VSCode with only valid project roots.
We could also update the code that generates the workspaces. But I don't think that's correct because then I couldn't use VS Code to edit the common logging code, for example.
Is your feature request related to a problem? Please describe.
As a core developer, it's very easy for me to create a mixed mode workspace and hit actively unsupported behavior as noted in lightning-lsp-common/src/shared.ts. When I do these behaviors, the LWC extension doesn't load and I don't get its benefits.
My workspace (and every core dev's workspaces) is generated based on local partial build config, so it's easy to hit one of these traps.
Describe the solution you'd like
Enhance the detection in shared.ts to return
WorkspaceType.CORE_PARTIALappropriately for workspaces generated by our internal build tools. I think this would be a really simple change actually. The workspace detection just needs to look up 1-5 parent directories for a "workspace-user.xml" instead of lookup up just a single parent directory.Describe alternatives you've considered
While developing PR #558, I strategically deleted parts of my generated code-workspace file, and then launched VSCode with only valid project roots.
We could also update the code that generates the workspaces. But I don't think that's correct because then I couldn't use VS Code to edit the common logging code, for example.
Additional context
Internal thread with discussion of #558.