More flexibility in root_dir selection inside a workspace for large monorepo

[GuillaumeLagrange]

Feature description

Hello !

First of all, thanks for the awesome and clean plugin.
LazyVim just switched to this plugin and I am having some issues due to a weird workflow on my end.

I work in a very big Rust monorepo, with hundreds of crates in a single workspace, and the workaround for dev sanity has been to use local .vscode/settings.json for each crate to override the rust analyzer check command to scope the lsp checks to the crate the dev is working on, since most people work on VSCode.

Until now, since rust-tools used nvim-lspconfig, there was some sort of a hack that would rely on neoconf and set the root_dir to wherever .vscode/settings.json was used. It is dirty, but it worked well and loaded the settings as expected.

I was thinking of using the dynamic settings, but it seems some smart autodetection is done here which forces the workspace root to be given to the load_rust_analyzer_settings function.

Right now, by forking and prioritizing the crate root in the dirtiest way possible it works fine, but I was wondering if this could be a config option ? Let me know if this is already too specific of a use case 😬

The next step for my workflow would be to make use of the workspace/didChangeConfiguration notification on buffer enter so that the check command is updated whenever I open a file from another workspace, but this is starting to be very specific, so I can implement this in my own config if you think no one will be interested.

[mrcjkb]

Hey 👋
Thanks for the nice words 😄

Do you have a qualitative example of what setting the workspace root via .vscode/settings.json looks like?
I presume it's related to this feature?
Maybe the best solution is to support that directly.

The next step for my workflow would be to make use of the workspace/didChangeConfiguration notification on buffer enter so that the check command is updated whenever I open a file from another workspace.

That sounds reasonable, if rust-analyzer supports changing the configuration on the fly.

[mrcjkb]

Possibly related for your use case: LazyVim/LazyVim#2720

[GuillaumeLagrange]

Thanks for your time !

Do you have a qualitative example of what setting the workspace root via .vscode/settings.json looks like?

Here is a very minimal repro repo that I used to troubleshoot before.

There are two service, and as I see it ideal behavior would be

• Have a single rust-analyzer instance running no matter what
• When entering a file, dynamically apply the check command override
• If automated change is not ideal, we could have a manual trigger which would identify the crate from the current buffer and send the config change to rust analyzer

I presume it's related to this feature?

We do not use them for now, but this is definitely the cleanest way of doing this, so it would solve my problem indeed.

[mrcjkb]

Thanks.
I'll look into adding support for it.

We do not use them for now, but this is definitely the cleanest way of doing this, so it would solve my problem indeed.

I had a closer look at it - multi-root-workspaces seems to be out of scope for rustaceanvim, as neovim doesn't have a concept of workspaces or projects. Something like that would probably be better handled by a dedicated plugin, like project.nvim.

[GuillaumeLagrange]

Agreed, I don't think it's this plugin's responsibility.

If you do not have time to look into solving my issue, I will look into it over the week-end and propose a PR if I can.