| Age | Commit message (Collapse) | Author | Files |
|---|
|
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.
|
