-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethink/rework the Che workspace with workspace-roots #15529
Comments
Number 4 would likely have to be configured in the devfile. For doing it by hand, we would have to write special UI, I guess, since only subpaths would be allowed. Checkout would still always be to /projects, though. |
Yes, i have a proposal in #15347 |
I've added languages as label but it might be as well editor or plug-ins |
A few words about Go extension which uses gopls (language server for Go). If the project uses Go module, it requires you to open the project as your workspace root. Some improvements should be done in the next v0.5.0 release: https://github.com/golang/go/milestone/138 |
The behaviour for workspace roots is different depending on the workspace, project and language server. I believe we'll have to have some way to configure where to open a workspace root given a project structure. Also think about opening multiple projects inside a monorepo. This would require support in the devfile format. |
The recently-added Scala plugin has the same limitation: eclipse-che/che-plugin-registry#356 |
Issues go stale after Mark the issue as fresh with If this issue is safe to close now please do so. Moderators: Add |
multi-root mode is already present in Che-Theia |
this was an umbrella issue, sub issues like #15347 were not covered |
Closing as we are sunsetting che-theia |
Is your enhancement related to a problem? Please describe.
At the moment, a lot of vscode extensions are relying on workspace root to work properly, the ones I have identified:
It means that we are getting through a lot bugs if we don't handle it properly. Basically, all these extensions are assuming that a project (maybe a subfolder of a git repo or not) is configured as a workspace root.
Describe the solution you'd like
The goal of this issue is to rethink the way we handle projects and create sub issues to fix all theses problem:
/projects
as a workspace root unless if there is no project defined in the devfile. By default, all projects in theprojects
section of the devfile should be a workspace root. Multi-root Che Theia Workspaces #17212sparseCheckoutDirs
should have sparseCheckoutDirs as a workspace root folders multiroot + sparseCheckoutDir should have sparseCheckoutDir as a workspace root #19370So we do not show anymore
/projects
as workspace root in the explorer. So, be careful not to break all the behaviors that are related to the current default workspace root/projects
.The text was updated successfully, but these errors were encountered: