jose-elias-alvarez
commented
3 years ago One potential solution – and the only one that I can think of that remains remotely near the scope of this plugin – is to create a custom handler for code action requests that'll create synthetic actions from ESLint JSON output and add them to the actual LSP code actions. (I don't have experience with TSLint or stylelint, but I imagine the process would be similar.)
That would entail running the current file through a linter whenever the user requests code actions, which wouldn't be great for performance (though something like eslint_d would help greatly).
Frankly, I think the only way to replicate the coc-eslint experience would be to write an actual language server that handles both getting the diagnostics and creating code actions from suggestions. Still, the custom handler solution might be an acceptable stopgap for people who are okay with the performance hit, so I'll give this some more thought and play around with it for now.
Let me know what you think and if you (or anyone else!) has any ideas for how this might be implemented.
VVKot
Curious if you'd be interested in including this in your plugin or should this go someplace else? The last blocker for me to jump the ship from CoC to native LSP is great code actions integration from coc-eslint, coc-tslint, coc-stylelint, etc. Generic language servers like diagnosticls work fine - but they don't produce code actions. It seems that, for example, coc-eslint has bits of code the converts suggested fixes into actions, so we need the matching code for native LSP somewhere.