feature suggestion: locally back-up lockfile automatically upon Lazy sync

[fdschmidt93]

Did you check the docs?

• I have read all the lazy docs

Is your feature request related to a problem? Please describe.

The lockfile is recommended to be synced with dotfiles on git. Of course, this is desired behavior, but not every user syncs their dots on git and, if so, syncs them often enough (like myself.. ;).

Consequently, a user might :Lazy sync and break something without being able to :Lazy restore as the lockfile has been overwritten.

Apologies in case I missed something obvious.

Describe the solution you'd like

Automatically back-up lockfiles to desired folder upon opt-in:

Define

• where to store to
• filename pattern
• how many past lockfiles to store

Describe alternatives you've considered

My simple implementation (to be polished if desirable for lazy.nvim)

vim.api.nvim_create_autocmd("User", {
  pattern = "LazySync",
  callback = function()
    local uv = vim.loop

    local config = vim.fn.stdpath "config"
    local NUM_BACKUPS = 5
    local LOCKFILES_DIR = string.format("%s/lockfiles/", config)

    -- create if not existing
    if not uv.fs_stat(LOCKFILES_DIR) then
      uv.fs_mkdir(LOCKFILES_DIR, 448)
    end

    local lockfile = require("lazy.core.config").options.lockfile
    if uv.fs_stat(lockfile) then
      -- create "%Y%m%d_%H:%M:%s_lazy-lock.json" in lockfile folder
      local filename = string.format("%s_lazy-lock.json", os.date "%Y%m%d_%H:%M:%S")
      local backup_lock = string.format("%s/%s", LOCKFILES_DIR, filename)
      local success = uv.fs_copyfile(lockfile, backup_lock)
      if success then
        -- clean up backups in excess of `num_backups`
        local iter_dir = uv.fs_scandir(LOCKFILES_DIR)
        if iter_dir then
          local suffix = "lazy-lock.json"
          local backups = {}
          while true do
            local name = uv.fs_scandir_next(iter_dir)
            -- make sure we are deleting lockfiles
            if name and name:sub(- #suffix, -1) == suffix then
              table.insert(backups, string.format("%s/%s", LOCKFILES_DIR, name))
            end
            if name == nil then
              break
            end
          end
          if not vim.tbl_isempty(backups) and #backups > NUM_BACKUPS then
            -- remove the lockfiles
            for _ = 1, #backups - NUM_BACKUPS do
              uv.fs_unlink(table.remove(backups, 1))
            end
          end
        end
      end
      vim.notify(string.format("Backed up %s", filename), vim.log.levels.INFO, { title = "lazy.nvim" })
    end
  end,
})

I very well understand if this should not land in lazy.nvim; I actually without success tried just sharing it on the neovim subreddit, but despite successfully posting before (e.g. about telescope-file-browser.nvim I maintain), my posts almost immediately get removed 🤷‍♂️

So sharing it here for your consideration.

Additional context

Happy to polish this as a PR if feature is desirable.

[folke]

I'm not planning to add something like this, however, what i am planning to add is that you can press r on a commit hash from lazy log to restore a plugin to that specific revision. Would that at least partially solve your issue of quickly reverting to a previous commit?

[folke]

Damn, why would your post get removed? That doesn't make sense. One of the mods must not like lazy 😉

[fdschmidt93]

I'm not planning to add something like this, however, what i am planning to add is that you can press r on a commit hash from lazy log to restore a plugin to that specific revision. Would that at least partially solve your issue of quickly reverting to a previous commit?

Sounds like a clean alternative to my idea! I'm not sure, maybe this could be a bit unwieldy if a plugin breakage a) actually keeps nvim from starting correctly (maybe? I think lazy.nvim always starts first anyways?) or (b) would be caused by intertwining plugins. In the telescope.nvim-ecosystem this occurred once or twice due to the interplay with plenary.nvim but, practically speaking it was pretty much always users not fully and cleanly updating. Just food for your thought though :) If it works reliably, your suggestion is of course much more ergonomic.

Damn, why would your post get removed? That doesn't make sense. One of the mods is probably fed up with all the lazy posts lately

No clue, my post was actually quite elaborate 😅

Anyways, I think we can close this as the original "issue" will as I understand be addressed eventually.

E: And of course thank you for a nice and simple plugin manager without headaches :)

[folke]

I'll keep it open for now so I don't forget adding that functionality 😅

Lazy should not really break on failing plugins or incorrect specs. You'd just see a fancy error about what plugin broke and what it did.

[folke]

You can now use <r> to restore plugins to the commit under the cursor