Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: config() function is run before plugin's scripts in plugin/ dir #328

Closed
3 tasks done
jdrouhard opened this issue Jan 5, 2023 · 3 comments · Fixed by #329
Closed
3 tasks done

bug: config() function is run before plugin's scripts in plugin/ dir #328

jdrouhard opened this issue Jan 5, 2023 · 3 comments · Fixed by #329
Labels
bug Something isn't working

Comments

@jdrouhard
Copy link
Contributor

Did you check docs and existing issues?

  • I have read all the lazy.nvim docs
  • I have searched the existing issues of lazy.nvim
  • I have searched the exsiting issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.9.0-dev-608+geb702273c

Operating system/version

MacOS 13.1

Describe the bug

Not sure exactly when, but recently my config function for vim-dispatch stopped working:

local M = {
  'tpope/vim-dispatch',
  cmd = { 'Dispatch', 'Make', 'Focus', 'Start' },
  dependencies = {
    'radenling/vim-dispatch-neovim',
  },
}

function M.config()
  local handlers = vim.g.dispatch_handlers
  table.insert(handlers, 1, 'neovim')
  vim.g.dispatch_handlers = handlers
end

return M

The config function modifies a list that the main vim-dispatch plugin file sets up. This was working until a recent update. The error is:

Error  12:18:56 notify.error lazy.nvim Failed to run `config` for vim-dispatch

/Users/jdrouhard/.config/nvim/lua/plugins/dispatch.lua:11: bad argument #1 to 'insert' (table expected, got nil)

# stacktrace:
  - ~/.config/nvim/lua/plugins/dispatch.lua:11 _in_ **config**

Steps To Reproduce

Using the attached minimal init.lua, do the following:

$ mkdir repro && cd repro
$ <put repro.lua from issue here>
$ mkdir -p test_plugin/plugin
$ cat > test_plugin/plugin/test.vim <<EOF
if !exists('g:my_list')
  let g:my_list = [
    \ 'item1',
    \ 'item2'
    \ ]
endif
EOF
$ nvim -u repro.lua

After the assert failure you'll see, you can run :lua=vim.g.my_list to see that the list is actually there, but the file wasn't sourced until after the config() function was called.

Expected Behavior

Files in plugins' plugin/ dirs should be sourced before the config() function from the plugin spec is called. This lets a user override things that a plugin sets up.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  -- add any other plugins here
  {
    dir = vim.fn.fnamemodify("./test_plugin", ":p"),
    config = function()
      assert(vim.g.my_list)
    end
  }
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here
@jdrouhard jdrouhard added the bug Something isn't working label Jan 5, 2023
@folke folke closed this as completed in 2ef44e2 Jan 5, 2023
@folke
Copy link
Owner

folke commented Jan 5, 2023

This is indeed due to a recent change where we now run config() before /plugin, because not doing it like that broke some plugins.

I do however agree with you that it makes more sense to load a plugin first and only then call setup, so I'll change that again. Your use-case is a great example.

@folke
Copy link
Owner

folke commented Jan 5, 2023

See also nvimdev/dashboard-nvim#222 (comment)

@flrgh
Copy link

flrgh commented Jan 5, 2023

I was simultaneously debugging and typing up my own report about this when I refreshed github and found that this other issue was filed and already fixed.

I do however agree with you that it makes more sense to load a plugin first and only then call setup

This is my opinion as well. Though the docs don't state this explicitly, it seems intuitive that plugin.config() should be allowed to depend on all the APIs (lua and vimscript) provided by the plugin.

Thanks all! 🏆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants