Perhaps you don't need a Zsh plugin manager after all

🤔 perhaps you don't need a Zsh plugin manager after all...

TLDR; You don't need a big bloated plugin manager for your Zsh plugins. A simple ~20 line function may be all you need.

Click here to skip to the code.

There are an embarrassingly large number of Zsh plugin managers out there. Many of them are abandonware, are no longer actively developed, are brand new without many users, or don't have much reason to even exist other than as a novelty.

Here's a list of many (but certainly not all) of them from awesome-zsh-plugins:

Full disclosure, I'm the author of one of these - antidote (formerly called pz).

There's new ones popping up all the time too:

In January 2021, the plugin manager I was using, antibody, was deprecated. The author even went so far as to say:

Most of the other plugin managers catch up on performance, thus keeping this [antibody] does not make sense anymore.

Prior to that, I used zgen, which also stopped being actively developed and the developer seems to have disappeared. (Shoutout to @jandamm for carrying on Zgen with Zgenom!)

In November 2021, a relatively well known and popular Zsh plugin manager, zinit, was removed from GitHub entirely and without warning. In fact, the author deleted almost his entire body of work. Zinit was really popular because it was super fast, and the author promoted his projects in multiple venues for many years. (Shoutout to zdharma-continuum for carrying on with zinit!)

With all the instability in the Zsh plugin manager space, it got me wondering why I even bother with a plugin manager at all.

After antibody was deprecated, I tried znap, but it was in early development at the time and kept breaking, so like many others before me, I decided to write my own - antidote.

When developing antidote, my goal was simple - make a plugin manager that was fast, functional, and easy to understand - which was everything I loved about zgen and antibody. While antidote is a great project, and I fully recommend it if you want to use a plugin manager, I kept wondering if I could cut further down to a single function and see what it would take to not use plugin management utilities altogether.

Thus was born... zsh_unplugged.

This isn't a plugin manager - it's a way to show you how to manage your own plugins using small, easy to understand snippets of Zsh. All this with the thought that perhaps, once-and-for-all, we can demystify what plugin managers do. And for basic configs do away with using a plugin manager altogether and simply do it ourselves.

You can grab a ~20 line function and you have everything you need to manage your own plugins from here on out. By way of contrast, I ran scc against the zinit project which comes out to thousands of lines of Zsh code, along with thousands of lines in supporting project files.*!

Results:

*Note: SLOC is not intended as anything more here than a rough comparison of effort, maintainability, and complexity

If you don't want to use anything resembling a plugin manager at all, you could simply clone and source plugins yourself manually:

This can get pretty repetitive, cumbersome, and tricky to maintain. You need to figure out each plugin's init file, and sometimes adding a plugin to your fpath is required. While this method works, there's another way...

If we go one level of abstraction higher than manually calling git clone, we can use a simple function as the basis for everything you need to manage Zsh plugins:

That's it. ~20 lines of code and you have a simple, robust Zsh plugin management alternative that is likely as fast as most everything else out there.

What this does is simply clones a Zsh plugin's git repository, and then examines that repo for an appropriate .zsh file to use as an init script. We then find and symlink the plugin's init file if necessary, which allows us to get close to the performance advantage of static sourcing rather than searching for which plugin file to load every time we open a new terminal.

Then, the plugin is sourced and added to fpath.

You can even get turbocharged-hypersonic-load-speed-magic 🚀 if you really need every last bit of performance. See how here.

You are free to grab the plugin-load function above and put it directly in your .zshrc, maintain it yourself, and never rely on anyone else's plugin manager again. Or, this repo makes the plugin-load function available as a plugin itself if you prefer. Here's an example .zshrc:

Here is an sample .zshrc.

Yes! This project uses the unlicense. Feel free to use this code anywhere. Or, if you prefer to use something already built and supported, this project includes its own implemetation of a micro plugin manager in the antidote.lite.zsh file. It's ~100 lines of code.

You can view a full featured example of using zsh_unplugged in the full_featured.zsh example file.

Updating your plugins is as simple as deleting the $ZPLUGINDIR and reloading Zsh.

If you are comfortable with git commands and prefer to not rebuild everything, you can run git pull yourself, or even use a simple plugin-update function:

You can see what plugins you have installed with a simple ls command:

If you need something fancier and would like to see the git origin of your plugins, you could run this command:

You can just remove it from your plugins list in your .zshrc. To delete it altogether, feel free to run rm:

You can get turbocharged-hypersonic-load-speed-magic if you choose to use the romkatv/zsh-defer plugin. Essentially, if you add romkatv/zsh-defer to your plugins list, everything you load afterwards will use zsh-defer, meaning you'll get speeds similar to zinit's turbo mode.

Notably, if you like the zsh-abbr plugin for fish-like abbreviations in Zsh, using zsh-defer will boost performance greatly.

⚠️ Warning - the author of zsh-defer does not recommend using the plugin this way, so be careful and selective about which plugins you load with zsh-defer. If you get weird behavior from a plugin, then load it before zsh-defer. In my extensive testing, the biggest benefit came only from especially sluggish plugins like zsh-abbr.

You can separate the clone and load actions into two separate functions, allowing you to further customize how you handle plugins. This technique is especially useful if you are using a project like zsh-utils with nested plugins, or using utilities like zsh-bench which aren't plugins.

You can then use these two functions like so:

Here is a sample .zshrc.

If you are an experienced Zsh user, you may know about zcompile, which takes your Zsh scripts and potentially speeds them up by compiling them to byte code. If you feel confident you know what you're doing and want to eek every last bit of performance out of your Zsh, you can use this function:

Oh-My-Zsh and Prezto have their own built-in methods for loading plugins, they just don't come with a way to clone them. You don't need the zsh_unplugged script if you are using those frameworks. However, you also don't need a separate plugin manager utility. Here's how you handle cloning yourself and go plugin-manager-free with Zsh frameworks:

If you are using Oh-My-Zsh, the way to go without a plugin manager would be to utilize the $ZSH_CUSTOM path.

Note that this assumes your init file is called {plugin_name}.plugin.zsh which may not be true.

If you are using Prezto, the way to go without a plugin manager would be to utilize the $ZPREZTODIR/contrib path.

Note that this assumes your init file is called {plugin_name}.plugin.zsh which may not be true.