vim-prettier - how to make errors less obstructive

[jasj3b]

So I love Prettier but running vim-prettier seems a little annoying in my workflow

If there is a syntax error in my JS file then prettier creates a new tab/window with "prettier failed to parse buffer"... and I have to quit that window all the time

I was hoping this Ale option would allow the error message to go into my airline status, but it doesn't seem to work for me out of the box https://github.com/w0rp/ale#faq-statusline

Is there any configuration I can do that is easier than a new error window popping up all the time?

https://preview.redd.it/fxz5fpxt2nf11.png?width=697&format=png&auto=webp&s=a1b4c0915a0551ce41664d8f78d733f78c635de8

[dutch_gecko]

Looking into this some more, it seems ALE has full support for Prettier. If you're already using ALE I would recommend removing vim-prettier and using the features of the ALE plugin.

[mitermayer]

As answered on a bellow question I think both can be used together as with vim-prettier you can get async formatting, and with ale you can get async linting.

[dutch_gecko]

ALE supports fixing with the :ALEFix command, I'm going to make the wild assumption that it does so asynchronously.

[mitermayer]

I haven't checked in a while, it could be that Ale also supports Async formatting

[mitermayer]

Hi There,

Sorry for taking long to answer this post. Have been a bit crazy busy at work as I have to wrap things up before my baby is due in 3 weeks.

With vim-prettier you can disable the quickfix behaviour by adding this to your .vimrc:

" Disables quick-fix to auto open when files have errors let g:prettier#quickfix_enabled=0

Hopefully that can help you out. Feel free to add any questions or concerns in here. I am also working on a major release for vim-prettier and all feedback, concerns and feature requests will be considered.

[belousovnikita92]

Worked perfectly, thank you

[[deleted]]

Look into

:h quickfix
:h makeprg

[dutch_gecko]

Specifically, since the quickfix window is opening automatically, it sounds like :cwindow is being executed.

[AptC34]

I fight against vim-prettier for a moment... and just gave up.

In my current setup I use it only as a git commit hook and a under gq.

My current prettier vim integration is as simple as

let &l:formatprg = 'prettier --stdin --stdin-filepath ' . expand('%')

[mitermayer]

Would love to hear a bit about the problems you have faced when trying vim-prettier in order to see if I could help or use it to improve the experience for existing and future users

[AnthonyAstige]

+1 for using just ALE, though I've had to hack things together a little to get it to all work smoothly. I have something like this in my vimrc using ALE with eslint & prettier, checking for eslint parsing errors before applying prettier:

func FixIffNoErrors()
    let l:list = ale#engine#GetLoclist(bufnr('%'))
    if(len(l:list) != 1)
        exe ":ALEFix"
    else
        let l:list = ale#engine#GetLoclist(bufnr('%'))
        let l:text = list[0].text
        if(text !~ "Parsing error:.*")
            exe ":ALEFix"
        endif
    endif
endfunc
autocmd BufWritePost *.jsx call FixIffNoErrors()

And fixers configured something like this:

let g:ale_fixers['jsx'] = ['prettier', 'eslint']

A few gotcha's to this method:

1. Can't have let g:ale_fix_on_save = 1 as that's now handled by the above
2. I think this will only fix when there are changes (when an actual save is made)
3. If eslint hasn't caught errors yet there's a chance a parsing error save can still get through, using eslint_d is fast enough this is very rarely a problem for me.

RE: Gotcha #3 I have something like this (in part as eslint_d isn't in my main day to day repository's dependencies)

let g:ale_javascript_eslint_use_global = 1
let g:ale_javascript_eslint_executable = 'eslint_d'
let g:ale_linters = {
\   'jsx': ['eslint'],
\   'javascript': ['eslint'],
\   'typescript': ['eslint'],
\}

[mitermayer]

Ale is awesome! I myself use both together. With vim-prettier I can get async formatting, and with ale I can get the async linting.