Configuring Ale to use project-specific tools in Vim
ESLint, Prettier and other tools all aid in the maintenance of a codebase, but not every codebase is the same. This means that globally installing these tools can cause issues if developers all have different versions of the tool installed.
The ideal scenario is that these tools are installed locally on a per-project
basis, with the text editor then loading these local copies for files located in
the project directory. Sometimes these tools aren't just installed in the root
node_modules
folder though.
Firstly, for Vim to use these tools, it needs a plugin to run them; Ale is one of the more popular Vim plugins that does just that, providing real time linting. It supports a large number of languages and tools, making it quite handy to have.
Ale provides two variables to configure a tool's executable path. Using ESLint as an example, these variables look like:
b:ale_javascript_eslint_executable
g:ale_javascript_eslint_executable
The b:
prefix references the buffer-specific value, and g:
references the
global value. Setting either of these values in a .vimrc
would look like this:
let b:ale_javascript_eslint_executable = '/path/to/project/node_modules/.bin/eslint'
let g:ale_javascript_eslint_executable = '/path/to/project/node_modules/.bin/eslint'
The problem that stems from this is that this value becomes the default for
every Vim buffer, regardless of whether the b:
or g:
value was set. When
multiple projects exist on the one machine (which is almost always likely to be
the case) this configuration will break linting for all other projects that use
ESLint.
The executable path should instead be set on a per-buffer basis, based on the
file path. This can be done using autocmd
:
autocmd BufRead,BufNewFile /path/to/project/* let b:ale_javascript_eslint_executable = 'path/to/project/node_modules/.bin/eslint'
The above line will only modify the executable path for ESLint for files located
within /path/to/project/
.
I'm sure there is probably a better way to deal with project-specific set up, but this does what I need and I have yet to experience any problems.
If you are in the position where you manage your .vimrc
in a repository but
only need to make these changes on a single machine, read my post on extending
a shared Vim configuration.