Skip to main content

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.

Added on 11 August 2018
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.