dense-analysis / ale

Check syntax in Vim/Neovim asynchronously and fix files, with Language Server Protocol (LSP) support
BSD 2-Clause "Simplified" License
13.56k stars 1.44k forks source link

When a typescript file fixes using prettier_eslint, it writes debug info to current buffer #1474

Open megalithic opened 6 years ago

megalithic commented 6 years ago

Information

VIM version

NVIM v0.2.2 Build type: Release

Operating System: macOS 10.13.3

:ALEInfo

Current Filetype: typescript
Available Linters: ['eslint', 'tslint', 'tsserver', 'typecheck']
  Enabled Linters: ['eslint']
 Linter Variables:
 Global Variables:
let g:ale_cache_executable_check_failures = 0
let g:ale_change_sign_column_color = 0
let g:ale_command_wrapper = ''
let g:ale_completion_delay = 100
let g:ale_completion_enabled = 0
let g:ale_completion_max_suggestions = 50
let g:ale_echo_cursor = 1
let g:ale_echo_msg_error_str = 'Error'
let g:ale_echo_msg_format = '%code: %%s'
let g:ale_echo_msg_info_str = 'Info'
let g:ale_echo_msg_warning_str = 'Warning'
let g:ale_enabled = 1
let g:ale_fix_on_save = 1
let g:ale_fixers = {'typescript': ['prettier', 'eslint', 'prettier_eslint'], 'javascript': ['prettier', 'eslint', 'prettier_eslint']}
let g:ale_history_enabled = 1
let g:ale_history_log_output = 1
let g:ale_keep_list_window_open = 0
let g:ale_lint_delay = 200
let g:ale_lint_on_enter = 1
let g:ale_lint_on_filetype_changed = 1
let g:ale_lint_on_save = 1
let g:ale_lint_on_text_changed = 'always'
let g:ale_lint_on_insert_leave = 0
let g:ale_linter_aliases = {}
let g:ale_linters = {'typescript': ['prettier', 'eslint'], 'javascript': ['prettier', 'eslint']}
let g:ale_linters_explicit = 0
let g:ale_list_window_size = 10
let g:ale_list_vertical = 0
let g:ale_loclist_msg_format = '%code: %%s'
let g:ale_max_buffer_history_size = 20
let g:ale_max_signs = -1
let g:ale_maximum_file_size = 0
let g:ale_open_list = 0
let g:ale_pattern_options = {}
let g:ale_pattern_options_enabled = 0
let g:ale_set_balloons = 0
let g:ale_set_highlights = 1
let g:ale_set_loclist = 1
let g:ale_set_quickfix = 0
let g:ale_set_signs = 1
let g:ale_sign_column_always = 0
let g:ale_sign_error = '✖'
let g:ale_sign_info = '⚠'
let g:ale_sign_offset = 1000000
let g:ale_sign_style_error = '✖'
let g:ale_sign_style_warning = '⚠'
let g:ale_sign_warning = '⚠'
let g:ale_statusline_format = ['%d error(s)', '%d warning(s)', 'OK']
let g:ale_type_map = {}
let g:ale_warn_about_trailing_blank_lines = 1
let g:ale_warn_about_trailing_whitespace = 1
  Command History:
(executable check - success) /Users/me/code/myapp/node_modules/eslint/bin/eslint.js
(started) ['/usr/local/bin/zsh', '-c', '''/Users/me/code/myapp/node_modules/eslint/bin/eslint.js'' -f unix --stdin --stdin-filename ''/Users/me/code/myapp/app/javascript/index.tsx'' < ''/var/folders/h8/5640k_095771kqqc4k9cpp0h0000gn/T/
nvimkp7ZGq/4/index.tsx''']
(finished - exit code 1) ['/usr/local/bin/zsh', '-c', '''/Users/me/code/myapp/node_modules/eslint/bin/eslint.js'' -f unix --stdin --stdin-filename ''/Users/me/code/myapp/index.tsx'' < ''/var/folders/h8/5640k_095771kqqc4k
9cpp0h0000gn/T/nvimkp7ZGq/5/index.tsx''']
<<<OUTPUT STARTS>>>
=============
WARNING: You are currently running a version of TypeScript which is not officially supported by typescript-eslint-parser.
You may find that it works just fine, or you may not.
SUPPORTED TYPESCRIPT VERSIONS: ~2.7.1
YOUR TYPESCRIPT VERSION: 2.8.0-rc
Please only submit bug reports when using the officially supported version.
=============
/Users/me/code/myapp/index.tsx:1:0: Parsing error: Merge conflict marker encountered. [Error]
1 problem
<<<OUTPUT ENDS>>>

What went wrong

Upon writing to the buffer, the fixer for typescript runs, which for me is ['prettier', 'eslint', 'prettier_eslint'], and the following is written to the top of the buffer that was written to:

=============

WARNING: You are currently running a version of TypeScript which is not officially supported by typescript-eslint-parser.

You may find that it works just fine, or you may not.

SUPPORTED TYPESCRIPT VERSIONS: ~2.7.1

YOUR TYPESCRIPT VERSION: 2.8.0-rc

Please only submit bug reports when using the officially supported version.

=============

So, as you can see it literally wrote the contents of OUTPUT STARTS and OUTPUT ENDS to the buffer.

The fixer behavior, other than that, is exactly as expected. It is respecting my local .eslintrc, for prettier + eslint, aka prettier-eslint.

w0rp commented 6 years ago

Could you share your project configuration files in a GitHub repo? I'll need to install and configure everything exactly as you did to repeat the bug.

megalithic commented 6 years ago

@w0rp yes sir! thank you, i'll work on getting that to you. in the meantime, it looks like it's not just Ale, someone posted a similar issue with their SublimeText editor setup in the eslint-typescript-parser repo: https://github.com/eslint/typescript-eslint-parser/issues/463

I'll take a look at Ale's plugin fixer code and see if there is a way to disable writing that contents in OUTPUT STARTS and OUTPUT ENDS.

w0rp commented 6 years ago

I believe I added support for a post-processing function for fixing files, so it might be possible to remove those lines from the output before writing them to the buffer.

megalithic commented 6 years ago

hah, you read my mind; i was going to add something custom to my setup on buffer post-writing to deal with that scenario. your way is MUCH cleaner. :)

megalithic commented 6 years ago

@w0rp this can be closed, setting a no-op for the loggerFn property in your .eslintrc does the trick. though it would be nice to do something with the ALEFixPost processor. thanks!

@w0rp unfortunately, that doesn't do the trick. while it does prevent the incompatibility warning from being logged (which means ale doesn't write it to the buffer now), problem is, the fixing works correctly only when that is logged to the buffer, when i add the .eslintrc entry prescribed here: https://github.com/eslint/typescript-eslint-parser/issues/463#issuecomment-379396518, it no longer fixes on save as it did previously. However, it definitely does not write the incompatibility warning any longer.

So, I guess, I would love a small bit of direction for using that ALEFixPost event, I see that I can setup the autocmd, and want to do something like: au User ALEFixPost *.ts,*.tsx silent call RemoveTypescriptIncompatibilityBanner(). Though to be honest, since the delimiters i'd be using to grep on are similar to merge conflict markers, I'm not sure of the best/cleanest way to go about removing that block of text.

Would love, love, love yours or another vim-master's input, prodding, direction, mentoring.

Thanks!

w0rp commented 6 years ago

Have a look at autoload/ale/fixers/eslint.vim for an example of the process_with callback for fixers, and the documentation with :help ale-fix. It should be possible to modify the prettier-eslint fixer, or whichever one is at fault, so lines which look like those warning messages are removed. The callback receives the lines of output, and returns the modified lines of output.

megalithic commented 6 years ago

@w0rp thanks! i'm giving it a go here: https://github.com/megalithic/ale/commit/d5cc4775fcb14daa49442092fcd26f5d84a7637e

I know it's not right/working, and in general way off.. I'm very much new to vimscript, so still learning about the <List> primitive, etc. Though, pattern matching is nice.

It feels like I should check the first line in the list for matching and if it's a pattern similar to ====, then we set a boolean that identifies us being in "unwanted output mode", then we loop the lines of output in that a:output list, returning an empty list ([]), per the eslint fixer example, until we find the next pattern similar to ====, unset that boolean and output as per normal.

Thoughts, is there a more idiomatic way to do the suggested above?

megalithic commented 6 years ago

I've gone the easiest route and forked typescript-eslint-parser and just disabled logging that version mismatch warning. Not optimal, but when I have more time to learn vimscript stuff to properly implement stripping of those messages, I'll get back to it. Hopefully someone else can take up the cause. :)