feat - improve support for monorepos and fvm in monorepos #476
+198
−94
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.
flutter-tools uses the active buffer's LSP client's root_dir as the cwd for executing commands. This is fine for a single project repository as the root_dir is set to be that project's root directory. But when working with monorepos this approach does not work, as the LSP's root_dir is whatever project was first opened when attaching the LSP.
Also when using FVM, flutter-tools does not consider the possibility of having multiple flutter versions, and instead keeps attached
the first LSP that it found.
To properly support monorepos we then have to do two things:
for a .fvm folder, and then using that folder's flutter sdk.
This PR does precisely that, while also moving things around to keep code clean, here is a list of the changes done by scrolling-down-to-the-end-of-the-pr order:
root directory for the LSP
project root patterns until it finds the first one, which will then be used as the root directory for commands.
If it is unable to find a root directory by that method, we fallback to the old behaviour of returning the active lsp's root_dir
When using FVM this PR changes flutter-tools so that it might run multiple Dart LSP servers, I thought about giving an option of keeping only the most recently launched LSP and closing the rest since the Dart LSP can be quite resource intensive, but didn't go through implementing that since I don't really have the time right now.