extraConfig to pass into builtin plugin's `setup()`

[horriblename]

⚠️ Please verify that this feature request has NOT been suggested before.

• [X] I checked and didn't find a similar feature request

🏷️ Feature Type

API Additions

🔖 Feature description

I'd like to add custom options that should be passed into the setup function of builtin plugins,

✔️ Solution

I have an idea using a nix to lua transpiler.

Example:

# user's configuration
vim.filetree.nvimTree = {
   enable = true;
   openOnSetup = false;
   # this attrset will be transpiled into lua:
   extraConfig = {
      select_prompts = false;
      view = { width = 30; };
      renderer.special_files = ["Cargo.toml" "Makefile"];
      on_attach = { _type = "_rawLua", code = ''
         function(bufnr)
            vim.keymap.set("n", "x", ":DoSomething<CR>", {buffer=bufnr})
         end
      ''};
   };
};

should generate this lua code (except uglier):

require("nvim-tree").setup({
   open_on_setup = true,
   select_prompts = false,
   view = { width = 30 },
   renderer = {special_files = {"Cargo.toml", "Makefile"}},
   on_attach = function(bufnr)
      vim.keymap.set("n", "x", ":DoSomething<CR>", {buffer=bufnr})
   end
})

We'll have to rewrite existing options in terms of extraConfig instead:

options.vim.filetree.nvimTree = {
      enable = mkEnableOption "...";
      openOnSetup = mkOption { ... };
      extraConfig = mkOption {
         type = types.anything;
      };
};

# cfg = config.vim.filetree.nvimTree
config.extraConfig = {
   open_on_setup = cfg.open_on_setup
}

config.vim.luaConfigRC.nvimtreelua = nvim.dag.entryAnywhere ''
   require 'nvim-tree'.setup(${convertToLua cfg.extraConfig})
''

The transpiler

with some minor improvements we can use lib.nvim.lua.expToLua

~~The transpiler should convert a nix value into a lua value, the only restriction is lambdas aren't allowed.~~

~~I have a working implementation here~~

~~Example usage here~~

❓ Alternatives

No response

📝 Additional Context

No response

[NotAShelf]

This seems like an interesting idea that I am willing to go forward with. Makes writing modules and contributing to this flake easier, both of which I'd like to see.

The scope, however, will be huge and I cannot tell if we'll be able to implement all modules as is. As such, I'd like to suggest finishing 0.5 release (which focuses on language modules and LSP installations) and then start converting modules one by one in a separate branch after 0.5 has been released.