Best practices for setup with lazy.nvim?

[Jackaed]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

all of the above

Question

For loading with lazy.nvim, is it better practice to load mini.nvim plugins individually, such that they can all be lazy-loaded separately, or is it best to load the overall mini.nvim plugin and individually choose plugins from there? As of right now I'm going with the former, as it allows you to use the configuration syntax as specified by lazy.nvim, but switching between the two should be fairly trivial. What would give better startup times? Or is the difference negligible.

[echasnovski]

The main "distribution source" of 'mini.nvim' is the whole library. It will always have priority over standalone repositories which are semi-automatically synchronized with the changes in 'mini.nvim'.

As far as I can tell with 'folke/lazy.nvim', the standalone repos fit more to its declarative specification if you want to narrowly lazy load everything that can be lazy loaded. Like lazy load 'mini.completion' on InsertEnter event, etc.

If you don't really care about extra lazy loading, installing the whole 'mini.nvim' and then doing require('mini.xxx').setup() in the config field should be good enough. The benefit here is a more compact and easy-to-follow config, which is not nothing in my opinion.

The main argument that motivated creating a dual distribution model in the first place was that with standalone modules users get narrowly targeted changelog during updates only from modules they prefer to use. With the 'mini.nvim' library approach, there will be all kinds of fix(other) and test(module) types of commits. That is not necessarily a bad thing, as it allows spotting a feature users might not have realized they needed, but some people might not like it.

But in the end, the "official" suggestion here remains the same and is to use 'mini.deps' (with config similar to this) :)

---

The extra performance benefit of using the whole 'mini.nvim' library is that it adds only a single entry in runtimepath (collection of paths Neovim uses when searching for runtime stuff; like during any require('some.module') first time call, or setting a 'filetype', or syntax, etc.). If many modules are used, entries from using standalone repos might result in building up significant extra time spent searching in their paths. Full disclaimer: I did not conduct any benchmarking here to measure the effect, but I think it might be significant with active enough runtime usage compared to possible startup gains from standalone repos. So it is like a O(1) penalty on startup compared to O(n) penalty during runtime (albeit probably with very small constant).

[Jackaed]

Thank you for the very quick (and detailed) answer! I think, given that I'm not (yet) willing to migrate to mini.deps, I'll keep loading them individually, just because that better fits the lazy.nvim model of declaring plugins (mainly for my own internal satisfaction of maintaining consistency across my config, rather than for any particular technical reason).

Thank you for the great work on mini! I've managed to cut out huge chunks of my config thanks to it (and I'm particularly looking forward to mini.terminals).