Move metals-vscode to a subdirectory #1373
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR prepares the ground for folding https://github.com/scalameta/metals-languageclient back into this repo.
The general idea is that https://github.com/scalameta/metals-languageclient used to be used by coc-scala and metals-vscode, but since coc-scala is now deprecated it doesn't make much sense to split the common code to a separate repository any longer.
Still, I think it makes sense to keep
metals-languageclient
as a separate package for two reasons:Now, to achieve the goal, I would normally use a yarn workspace, which would look like this:
However, due to vsce not supporting yarn workspaces we cannot have a proper workspace, so each subdirectory will live on its own and we don't get features like symlinking or dependency hoisting and result in something like:
I think this is mostly fine; it will require some fiddling, but nothing too crazy.
And if microsoft/vscode-vsce#300 ever gets merged, we can then easily move to a proper workspace.
Once this PR lands, we can then add the contents of the
metals-languageclient
repo as a directory next tometals-vscode
. In order to do that preserving the git history, I will need to rewrite the repo history, so it would be better to cleanup the PR queue before that.