1

I have a few Neomake definitions which work well for me, but one thing I can't quite get my head around is automatic lint fixes with standard --fix. Here's what I have:

let g:neomake_javascript_standardfix_maker = {
    \ 'exe': 'standard',
    \ 'args': '--fix',
    \ 'errorformat': '%-G%.%#'
    \ }
let g:neomake_javascript_enabled_makers = ['standardfix', 'jest', 'standard']
call neomake#configure#automake('w')
set autoread
au FocusGained *.js :checktime

Unfortunately, the buffer doesn't update after standard --fix runs (although I've confirmed it does write the correct file with fixed syntax).

I suppose my ideal behaviour would be: linter fixes what it can fix, and location list pops open as it does now but with only those issues that --fix doesn't take care of automatically, like unused variables.

Rich Churcher
  • 7,361
  • 3
  • 37
  • 60

1 Answers1

0

I'm going to post an answer with my workaround solution (using ALE) in case it helps anyone else, but will accept any other answer that more directly addresses the question.

My main issue is that I don't use Neomake solely for linting: to take the example of JavaScript, it's being used as a test runner on save and I could see launching staging build tasks from it too (React Native test builds, for example). I think I have ALE and Neomake cooperating, at least to be going on with:

" Suppress ALE warning about conflicts with Neomake
let g:ale_emit_conflict_warnings = 0

" JavaScript make/test
highlight NeomakeErrorMsg ctermfg=1 ctermbg=18
highlight NeomakeWarningMsg ctermfg=16 ctermbg=18
let g:neomake_error_sign = {
    \ 'text': '●',
    \ 'texthl': 'NeomakeErrorMsg'
    \ }
let g:neomake_warning_sign = {
    \ 'text': '●',
    \ 'texthl': 'NeomakeWarningMsg'
    \ }
let g:neomake_open_list = 2

" This reads config from a file specifying a custom Jest
" reporter (see below) making it easier to parse output with
" a Vim errorformat 
let g:neomake_javascript_jest_maker = {
    \ 'exe': './node_modules/jest-cli/bin/jest.js',
    \ 'args': [ '-c=./vim-jest.json', '--no-watchman' ],
    \ 'errorformat':
        \ '%f:%l:%c:%t:%m,' .
        \ '%-G%.%#'
    \ }

" By setting this explicitly, we overwrite the default
" (so Neomake shouldn't attempt to launch standard/eslint)
let g:neomake_javascript_enabled_makers = ['jest']

call neomake#configure#automake('w')

" linting
let g:ale_sign_error = '▶▶'
let g:ale_sign_warning = '▶▶'
highlight ALEErrorSign ctermfg=1 ctermbg=18
highlight ALEWarningSign ctermfg=16 ctermbg=18
let g:ale_linters = {
    \ 'javascript': ['standard']
    \ }
let g:ale_fixers = {
    \ 'javascript': ['standard']
    \ }
let g:ale_fix_on_save = 1

My vim-jest.json contains any Jest config I need per project, at minimum this:

{
  "reporters": [ "jest-simple-reporter" ]
}

jest-simple-reporter is a very rough reporter I cooked up to distill Jest's rather rangy output down to one line per fixture. It does need to be installed in the current project's devDependencies though, because of the separate config for Vim, it doesn't need to be used in the test script or project Jest config.

Interestingly, when I turn off ale_fix_on_save, Neomake's warning/error signs seem to take precedence in the gutter. Only after I have the test passing do the linter's signs appear. Works pretty nicely, errors are fixed on save and those that can't be fixed are indicated, co-existing nicely with test failure signage.

Rich Churcher
  • 7,361
  • 3
  • 37
  • 60
  • If you're using ALE you don't need neomake – icc97 Feb 14 '19 at 20:02
  • I mentioned in the answer above that I wasn't using neomake for linting. – Rich Churcher Feb 14 '19 at 23:55
  • Ah, OK. I'm a bit confused though. *"I don't use Neomake solely for linting"* - implies that you are using it for linting + other things too. I found that neomake was faster for linting (at least when I tried with [eslint_d](https://github.com/mantoni/eslint_d.js)) but it still doesn't have a decent solution for applying linting fixies. For now I've just switched to ALE + eslint_d. – icc97 Feb 15 '19 at 09:23
  • I meant, I was also using it as a test runner so I couldn't just remove it entirely to avoid conflicting with ALE :) – Rich Churcher Feb 15 '19 at 22:23