This post is meant as constructive criticism, because the out of the box experience for the uninitiated JS developer is pretty rough. Keep in mind that ALE just works, and so does Visual Studio Code with the eslint plugin.
neomake by e.g., adding it to the plugin list.,.js file and run :Neomake -> Nothing happens. This is going to be the first hurdle since I assume people will have to first figure out that they can run :NeomakeInfo. But this is also out of scope for the eslint specific isssues, so moving on.:NeomakeInfo shows - WARNINGS:
- maker's exe (eslint) is not executable.
neomake assumes linters to be available globally because in many (most?) languages that's how it works. But we absolutely need the local eslint because a global eslint is pretty much useless (plugin version mismatch).let b:eslint_exe = substitute(system('npm bin') ,'\n', '', 'g') . '/eslint'
let b:neomake_eslint_exe = b:eslint_exe
.js file again, run :Neomake and see too many errors. The cwd is now set to the folder of the current file and at least in our codebase at work this breaks absolute imports like import Foo from 'components/Foo' which use the webpack and eslint resolve plugin and which works in ALE and VSC.exe the user might now try to do the same with cwd but as far as I can see from :h neomake that's not actually possible because it's not part of the maker properties that can be set. I do understand that not everyone is a JS dev and that eslint is a bit of a special snowflake. But I really like neomake and I'd love to make it easier for JS devs. What would help is a FAQ entry which outlines the issue (neomake uses global binaries) and proposes a solution (with a link to an issue where people can find more help) which ideally doesn't require additional vimscript files and functions. I also think that cwd should be easier to override or that the object/record way of creating makers can somehow be merged into the defaults for that maker rather than overriding it entirely.
Thanks for neomake 馃崿 馃帄
i agree with this, i have a bunch of boilerplate that sets up eslint to run using npx in the cwd (so it will download and use a temporary global version if 1) local version not available, 2) global version not available)
you can check it out here https://github.com/davidosomething/dotfiles/blob/dev/vim/autoload/dko/neomake/javascript.vim
i'll try to port these changes in at some point, but given this if you want to give it a shot go for it!
Thanks for the issue and the clear outline.
Some quick response already:
In general the best fix is to make custom linters available on your $PATH, i.e. from node_modules/.bin.
But I also agree that it could be either made easier to do this automatically (there are helpers for finding the project root already for example), and that documentation could be improved in this regard.
If I find some time I'll try to improve the documentation!
This issue should have actually resolved itself with ESLint 6. ESLint now resolves plugins and configs relative to the project. So at least in my case I can run a globally installed eslint on our project at work which has a lot of custom stuff and It Just Works. That also means that neomake should be free to use the global eslint https://eslint.org/docs/user-guide/migrating-to-6.0.0#package-loading-simplification
@cideM thanks for the update, closing then.
Just one final comment, since the cwd issue remains (I don't actually know why eslint has cwd set to %:p:h per default): I'm currently getting around the limitation with this in after/ftplugin/javascript.vim
let eslint = neomake#makers#ft#javascript#eslint()
call remove(eslint, 'cwd')
let eslint.exe = 'eslint'
let g:neomake_javascript_eslintcustom_maker = eslint
This will re-use the existing maker and just remove the cwd property from it. In my case I'm then defining it as a new maker, which now uses the globally installed eslint.
Most helpful comment
i agree with this, i have a bunch of boilerplate that sets up eslint to run using npx in the cwd (so it will download and use a temporary global version if 1) local version not available, 2) global version not available)
you can check it out here https://github.com/davidosomething/dotfiles/blob/dev/vim/autoload/dko/neomake/javascript.vim
i'll try to port these changes in at some point, but given this if you want to give it a shot go for it!