Don't think adding global variables is the desired solution.

Don't think adding global variables is the desired solution.

I disagree, this is regarded as the best practice to allow users to disable your plugin from loading, and or for it not to redo it's work (which might e.g create duplicate autocmd). Source with respect to regarded:
examples of a few popular plugins (by vim-awesome):

• vim-fugitive
• vim-surround
• nerd-tree
• syntastic

It should be achievable without global variables though.

In lua, we can use package.loaded[mod]

- if vim.g.loaded_cmp_nvim_lsp then
+ if package.loaded['cmp_nvim_lsp'] then
    return
  end
- vim.g.loaded_cmp_nvim_lsp = true

  require("cmp_nvim_lsp").setup()

I think global load_... variables for plugin is fine, as it's a very common convention.

Common from vim as there was no other way. @fitrh solution is way cleaner.

I prefer @fitrh's method.
Could you please change it like that?

While I understand the point as to why you would prefer the latter method in a Lua package. I might offer one last disadvantage, that is that we're not compatible with the way you can disable builtin plugins in Neovim using:

local disabled_builtin_plugins = {
    "netrw",
   -- ...
}

for _, plugin in ipairs(disabled_builtin_plugins) do
    vim.g["loaded_" .. plugin] = true
end

If regardless of that we still want this change I'll make the adjustment.

I prefer @fitrh's method. Could you please change it like that?

Done

I am not convinced package.loaded is cleaner. Even for a pure Lua solution.

If I do require('cmp_nvim_lsp').default_capabilities() in my lsp setup called by my init.lua, this sets the package.loaded.cmp_nvim_lsp variable. init.lua gets ran before the plugin dirs are sourced. That then prevents this hook from running require('cmp_nvim_lsp').setup(), thus still requiring me to manually call setup.

vim.g.loaded_pluginname has been a standard for like 20 years for a reason.

I would suggest revising this change to use vim.g personally. I feel using package.loaded violates the single responsibility principle thus causing possible issues like the above, and in addition vim.g. has better compatibility with vimscript