| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem:
An inherited Git index can leave a plugin checkout empty or prevent
updates.
Solution:
Clear GIT_INDEX_FILE for plugin Git commands. Verify installs and
updates preserve the caller environment and index.
AI-assisted
Signed-off-by: Jake Wang <jakezwang@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
| |
Problem: Argument type mismatches are excluded from EmmyLua checks.
Solution: Correct runtime annotations and calls, document local checker
workarounds, and enable the diagnostic.
AI-assisted
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Enable EmmyLua's need-check-nil diagnostic and resolve nullable values
through more precise types, explicit invariants, and guards for missing
runtime state. Keep analyzer-specific workarounds local and update the
affected API documentation.
Exclude the bundled re.lua from analysis so its nil-check warnings do
not fail CI.
AI-assisted
|
| |
|
|
|
|
| |
Problem: No explicit recommendations about how to check for possible
issues related to `vim.pack`.
Soltuion: Mention `:checkhealth vim.pack` explicitlye as a recipe.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: No way for plugins to define hooks that would be executed
during plugin lifecycle. Like after install/update or before
update/delete.
Solution: Automatically source scripts defined in plugin manifest file
(if any) after triggering corresponding `PackChanged{,Pre}` events.
During sourcing make some termporary adjustments:
- Current directory is set to plugin's root to simplify execution of
CLI calls like `make build`.
- Plugin's path is ensured to be inside 'runtimepath' to allow using
`require('plugin-module')` inside manifest scripts.
The reason to execute after triggering event is so that there is a
possibility for users to execute code both before the script (exactly
on event) and after the script (more-or-less via `vim.schedule` called
on the event).
|
| |
|
|
|
|
|
|
|
| |
Problem: There is no agreed way for plugins to provide extra information
about themselves. Like required Neovim version, install/update/delete
hooks, and dependencies.
Solution: Introduce basic concept of plugin manifest file `pkg.json`
based on https://packspec.org/.
|
| |
|
|
|
| |
Problem: No way to configure the lockfile location.
Solution: Add 'packlockfile' option.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Problem: If the lockfile points to the revision that is not on disk, the
`:checkhealth vim.pack` suggests to run `vim.pack.update()`. Although
usually it should resolve the problem, it is not always the case: like
if the state on disk is already the latest available.
Solution: Add an extra suggestion with a more drastic measure by
manually removing `rev` field from the lockfile for it to be repaired
after the `:restart`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem: It is possible (and documented in `:h vim.pack`) that plugin's
`src` uses "insteadOf" Git config. In that case comparing it directly
to repo's `origin` will error.
Solution: Add extra check that lockfile's `src` is not equal to repo's
`origin` when taking Git's "insteadOf" into account.
However, still report the original lockfile's `src` in the
`:checkhealth` output, as it seems to be a clearer indication of what
actually is wrong.
|
|
|
Problem: No `:checkhealth` entry.
Solution: Add `:checkhealth vim.pack`. Design it around validating
assumptions about `vim.pack` usage and giving actionable advice to fix
possible issues. In particular:
- Basic requirements are met: `git` executable, lockfile, and
plugin directory are present.
- Lockfile has correct shape (json with correct field types) and
aligns with plugins on disk (revision and source are as expected).
- Plugin directory has proper entries: all directories, in the state
that `vim.pack` might leave them.
Also notify if there are not active plugins. Those might be lazy
loaded (okay) or removed an entry from the config without
`vim.pack.del()` (not okay).
Make sure that it passes with brief feedback if it doesn't look like
`vim.pack` is being used.
Duplicate check for `git` executable (on top of already existing
very similar 'health/health.lua' check for "External tools") to have
it shown after `:checkhealth vim.pack`. Keep the other check for more
exposure and possibly for other plugins to reuse it.
|