[Feature] Add an API to support lazy loading plugins

[mrcjkb]

This would mean two things:

• [x] Change the installer to tell users to add vim.opt.runtimepath:append(vim.fs.joinpath(rocks_config.rocks_path, "lib", "luarocks", "rocks-5.1", "rocks.nvim", "*")) to their init.lua

• [x] Add an option to lazy load plugins to rocks.toml (see below snippet)

[plugins]
neorg = { opt = true, version = "1.0.0" }

• [x] Add a rocks.api.load_plugin(name) function :Rocks[!] packadd {rock} command that allows users or an external module to load plugins manually.

[NTBBloodbath]

To keep the lazy loading to just what is necessary, I think adding an opts table to the API function that accepts two possible arguments (ft and event) for faster integration could be nice. For example, to have nvim-lspconfig loaded only on certain filetypes in which you have its LSP installed in your system. Here is an example

--- Load lspconfig only in the following filetypes
--- as I have installed their LSPs for daily use
rocks.api.load_plugin("lspconfig", {
    ft = { "lua", "python", "haskell" },
})

Ps: will the function work based on the name of the plugin or the name of its Lua module (e.g. nvim-lspconfig or lspconfig)?

---

Edit: I don't think that both table options should coexist if implemented, I don't know if it could cause bugs in some plugins or create race conditions in some others.

Edit 2: I just saw the proposal for the rocks-lazy module and its possible configuration. Would the proposal mentioned here serve to make things easier or will an internal wrapper be created in that module?

[mrcjkb]

will the function work based on the name of the plugin or the name of its Lua module

plugin name.

I just saw the proposal for the rocks-lazy module and its possible configuration. Would the proposal mentioned here serve to make things easier or will an internal wrapper be created in that module?

I think the rocks.nvim API should be as simple as possible. That is, no lazy loading logic whatsoever. We just provide the API for loading the plugins manually, and the opt config option that allows users to prevent rocks.nvim from eagerly loading the plugins.

Any lazy loading logic and additional options should be the responsibility of the external module. For example rocks-git.nvim adds a bunch of fields (git, rev, build, ...) to the rocks.toml schema. rocks.nvim itself knows nothing about these fields. It simply sends the config to the injected handler, which detects if it has a git field and does something with it.