Are there plans for adding support for lockfile?

[WilliamHsieh]

It would be beneficial to have the capability to verify the version of installed plugins and to update them as required.

[mattmc3]

Can you describe more of what you're looking for here? Are you asking for the ability to pin a specific commit of a plugin like this or something else? Is there an example of a plugin where this feature would be beneficial?

[WilliamHsieh]

Are you asking for the ability to pin a specific commit of a plugin #1

Yes.

I recently configured a new machine using my dotfiles.
While the process went smoothly, I encountered a minor hiccup - some plugins broke after cloning the latest versions.

It would be a valuable enhancement if the plugin manager could incorporate lockfile support. This feature would allow users to consistently checkout a specific revision, making sure that all plugins are always working as expected.

I've been in the process of updating my zsh setup, and I stumbled upon this fantastic project! Thank you for your dedicated efforts in maintaining such an exceptional piece of software.

Additional context: a neovim plugin manager with lockfile support: https://github.com/folke/lazy.nvim

[jathek]

I was going to request something similar - a "check for updates but don't download" command, so I could review any changes before I pulled new versions.

[mattmc3]

I like this idea. Something like antidote update --dry-run?

[famiu]

This is a must have feature imho and I'm surprised that none of the Zsh plugin managers I checked have this feature. Not having a lockfile doesn't only harm reproducibility, but is also a serious security vulnerability that can be exploited.

[mattmc3]

This is in the works for v2. antidote will support a simple lockfile that maps all your repos to the current SHA.

My current thinking on a basic design is:

• If you run antidote update, git pulls will happen on anything not pinned, and the SHAs will advance, the old lockfile will be saved in $XDG_DATA_HOME/antidote, and a new one created in your $ZDOTDIR.
• If an update gives you trouble, you can rollback to one of the prior lockfiles using a new antidote rollback command that will let you pick an old lockfile.
• If you don't want a plugin to ever update, you can add a pin:true or pin:deadbeef annotation (assuming deadbeef is the SHA you want to pin to).
• Lockfiles will be enabled by default, and the location configurable
• If using a dotfiles repo, you should be able to check-in your current lockfile, and antidote will respect it when cloning/updating.

I don't have a great way to stop someone from force pushing to revise history, but we can ensure that if we cannot find the SHA, we won't load the plugin.