Is a require() not enough to ensure a plugin is loaded and config is called?

[sid-6581]

I'm using mason along with mason-lspconfig as well as mason-tool-installer, and this requires a certain order of initialization. mason needs to be initialized first, followed by mason-lspconfig, followed by nvim-lspconfig, etc. I have my mason setup in its own mason.lua with a config method, and I in my lspconfig setup I do a require("mason").

This alone doesn't seem to load mason and run the config function. If I keep my mason.lua as is and add "williamboman/mason.nvim" as a dependency of nvim-lspconfig instead of require("mason") in my lspconfig config, mason is loaded properly before my lspconfig setup.

@folke , I've used your dotfiles a lot for inspiration, and I have to admit your latest changes have me a bit confused. For mason you have ensure_installed directly in the plugin spec table instead of as part of config. Same thing with servers for nvim-lspconfig. In an earlier version I think I remember seeing you also doing require("mason"), but now I don't know what to think with the latest changes lol.

[folke]

Those ensure_installed etc are custom attributes of the plugin that I use in its plugin config. You can set any attributes you want.

My config extends the plugins from LazyVim, a new vim distro I'm making.

You can find the original specs here https://github.com/folke/LazyVim/blob/main/lua/lazyvim/plugins/lsp/init.lua

Those are loaded first by lazy and then my own specs that override anything that is in LazyVim.

I hope this now makes more sense :)

[sid-6581]

Does the require just trigger an async load of the plugin, with no guarantees it will be loaded and configured before continuing to the code after the require? I'm seeing different behavior on Linux vs Windows. On Linux it seems to behave as I would expect, with mason-tool-installer triggering the immediate loading of mason:

On Windows, with the exact same configuration, I get a completely different order, where mason isn't loaded until the very end. In this particular example it's not a problem, but if I also add in nvim-lspconfig, it will often (but not always, it's not consistent) load before mason, which causes all the lsp stuff to fail. Here is what it looks like on Windows:

Both of the above screenshots are without listing mason as a dependency, and just using require("mason").

If I remove the require and list mason as a dependency, I get the same result in Linux:

But Windows now looks different (and loads mason properly):

I'm not sure if the Windows loading is considered correct because there are no guarantees as to the order, or if this is a problem. I'm also not sure why nvim-lspconfig is loaded on Linux in both cases, but not loaded in either case for Windows. I'm not loading nvim-lspconfig myself in the configuration until BufReadPre which hasn't been triggered yet, so I wouldn't expect it to be loaded, but I would expect things to be a bit more deterministic between Linux and Windows.

If this is not the intended behavior I would be happy to do some more digging into lazy internals on Windows to see if I can determine what's causing it, but if this is expected behavior I can just use dependencies to force the order.

[folke]

That all looks right to me. It can be different on windows (or on linux) due to the async nature of Neovim. But mason would still be loaded where you did the require.

Your windows screenshots show loading of devicons in between, because the Neovim loop suspended the VimEnter of mason installer and did some other stuff first. After that it continues the installer handler and loads mason as you can see.

Is something not working? Or are you simply confused by the async profiling output?

If you think something is broken, then please create an issue with a minimal repro

[sid-6581]

Here is an example of things going wrong on Windows. I have require("mason") as the very first line in config for nvim-lspconfig, yet nvim-lspconfig/plugin/lspconfig.lua is loaded before mason. This causes the LSP servers to not load properly. Does that seem like a bug to you? If so, I can try to get a minimal repro and create an issue.

[folke]

No idea. Do you have recursive deps in there? Can you open an issue with the repro? Cant do much without seeing the actual config and repro

[sid-6581]

I definitely don't have any recursive dependencies in my setup, unless there are some internal recursive dependencies in the plugins I'm using. This same setup that fails on Windows works fine on Linux. Everything is initialized in the right order with just require, and the LSP servers load properly.

I was able to reproduce the issue with a minimal repro earlier, so I'll create an issue for it.