Is anything like neovim's null-ls supported by lsp-mode?

[ohmree]

I just found out about null-ls for neovim, is there any way to hook into, for example, the formatting for the typescript language server to make it use prettier?
Currently I have doom emacs configured to use format-all instead of lsp-mode for typescript which does work but its ui is a bit different to lsp-mode's and it feels a bit slower (although I'm not sure if there'll be any performance benefits with the approach null-ls takes, I think it depends on whether prettier runs in-process in the language server or is invoked separately).

I know it's possible to run multiple language servers in one buffer (like how eslint support is implemented in lsp-mode) but I feel like it'd be tedious to write an entire language server that just wraps a tool like prettier (or codespell, or cspell, or eslint, etc).

[yyoncho]

In emacs the problems that null-ls is solving do not exist in the first place because lsp-mode is just a normal backend for existing emacs pacakges like flycheck/flymake/helm/ivy/etc and you can always add advice over lsp-request to plug a particular data.

format-all instead of lsp-mode for typescript which does work but its ui is a bit different to lsp-mode

I don't understand that, can you elaborate?

[ohmree]

In emacs the problems that null-ls is solving do not exist in the first place

Fair enough, didn't think about that.

I don't understand that, can you elaborate?

When the buffer has syntax errors and you run format-all on it a new window opens showing you the error message from the formatter, which is redundant since lsp-mode already reports syntax errors and from a quick helpful-variable search I couldn't find anything that controls this behavior in format-all.

Now that I think about it this isn't really a big thing but it could be nice to have at least pluggable formatters and maybe code action and project/buffer diagnostics providers for lsp-mode that would run alongside those from the language server (or instead, in the case of the formatter).

[yyoncho]

When the buffer has syntax errors and you run format-all on it a new window opens showing you the error message from the formatter, which is redundant since lsp-mode already reports syntax errors and from a quick helpful-variable search I couldn't find anything that controls this behavior in format-all.

IMHO if there is no such variable to turn off that feature it will be easy to be added.

Now that I think about it this isn't really a big thing but it could be nice to have at least pluggable formatters and maybe code action and project/buffer diagnostics providers for lsp-mode that would run alongside those from the language server (or instead, in the case of the formatter).

You could do that by defining a checker and plug into flycheck/flymake. lsp-mode is not the thing that you plug in, but lsp-mode is plugging in the packages providing the particular feature. For example, lsp-mode sets indent-region-function and you can format with M-x ident-buffer. You can look for a package that provides such function. I can see there is https://github.com/prettier/prettier-emacs for example.

[elken]

The version of format-all pinned in doom is quite old and is currently being refactored by me.

The package it's being replaced with is apheleia which triggers on after-save rather than before-save and runs asynchronously to as to preserve (point) as best it can. I've been dogfooding it for a while, while working on the refactor when I can, and I can say it's much more reliable.

I believe yyoncho is correct that this problem doesn't really exist because of lsp-mode acting like a bridge for other packages to use.

So I guess the answer to your question is: no, nothing exists in LSP but other options exist in emacs.

[ohmree]

Hey, thanks for the reply.
Apheleia looks awesome, thanks for letting me know about it!

[elken]

No worries! There is a discussion over there about merging all the various formatter packages; but for now doom should still be going for apheleia and I'll revisit it further down the line :)