Skip to content

docs: clarify custom plugin load ordering - #2151

Open
TyceHerrman wants to merge 1 commit into
nvim-lua:masterfrom
TyceHerrman:docs/custom-plugin-load-order
Open

docs: clarify custom plugin load ordering#2151
TyceHerrman wants to merge 1 commit into
nvim-lua:masterfrom
TyceHerrman:docs/custom-plugin-load-order

Conversation

@TyceHerrman

Copy link
Copy Markdown

Summary

  • clarify that the custom-plugin convenience loader's file order is unspecified
  • recommend keeping dependent plugins in the same file
  • document explicit ordered requires for intentionally separate modules
  • place the same warning beside the loader implementation

The loader itself remains unchanged.

Closes #2038

Testing

  • stylua --check .
  • git diff --check

Comment thread init.lua
-- For independent modules, uncomment the convenience loader:
-- require 'custom.plugins'
--
-- `custom.plugins` automatically loads files from that directory, but their

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe out of scope for the PR, but why doesn't the repo recommand using the official after/plugin way? That would be more nvim native and would save a bit of complexity with the custom init.lua in lua/custom/plugins.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that could be a better approach, but it's a bigger change. files under after/plugin/ run in a later startup phase. During init.lua, vim.pack.add() defaults to load = false, and after init.lua it defaults to load = true. Moving the current vim.pack.add() and setup() calls into after/plugin/ would change when plugin scripts are loaded. This PR documents how the existing loader works, but Kickstart adopting after/plugin/ as its recommended extension layout would supersede it. so could be closed if that's the direction to go now, but if that needs further deliberation, could merge this PR as is imho

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Document explicit custom plugin requires when order matters

2 participants