The problem with a shared configuration

I manage my .vimrc via a dotfiles repository, which I probably take a little too much pride in. When I started sharing these dotfiles across machines I began to find it inconvenient when I needed to add machine-specific configuration for certain projects.

Making changes to my shared .vimrc would clutter my dotfiles repository with things that I never intended to commit. This would also apply for when I was installing plugins.

I could just ignore the diffs, but I personally prefer git status to be clean if I don't intend on committing the changes at some point.

How to extend a shared configuration per machine

The solution is to create a new package in Vim. By package, I refer to the following:

.vim/pack/<package-name>/

…where <package-name> is the name of the package.

In my dotfiles repository, I have defined the dfranklinau package, i.e.:

.vim/pack/dfranklinau/start/

…so to extend this shared configuration, I chose a generic package name of local:

.vim/pack/local/start/

All of the machine-specific plugins and Vim configuration can now be added under the local folder.

I have added this folder path to my .gitignore so that I won't clutter up my dotfile repository with unstaged changes.

Adding machine-specific configuration

To add machine-specific configuration, rather than changing .vimrc directly, a custom plugin should be created in the new "extends" package.

I did this following my Vim 8 package management guide. I created the following file and placed all of my project-specific Ale configuration inside:

.vim/pack/local/start/local/plugin/vimrc.vim

vimrc.vim acts as a standard .vimrc file so there's no changes to how commands are formatted. Because it lives inside the start folder, it is also loaded automatically when Vim is opened.

Adding machine-specific plugins

To add machine-specific plugins, clone the plugins into the new "extends" package.

That's all there is to it.

No, really. That's it.