Confused on how to use this in combination with nvim-lsp-ts-utils

[sQVe]

👋🏼

I'd first like to take my time and thank you for all your hard work improving the neovim eco system. Really appreciate it!

---

My confused on how I can setup null-ls together with the code actions available in nvim-lsp-ts-utils. I would preferably keep the linting and formatting in null-ls as I, frankly, think that API is superior and a lot more easy to understand.

It's very clear on how I would setup formatters and linters but I'm very confused on how I would setup the eslint code actions. Am I forced to use nvim-lsp-ts-utils in this case or can I just pull in a small part from it? It's just not clear to me how I can configure everything on a granular level if I combine nvim-lsp-ts-utils and null-ts. The ownership and responsibility is confusing.

All help greatly appreciated 🙏🏼

[sQVe]

I've now setup null-ls to handle linting and formatting and it's working great. Great API and much easier to setup and extend compared to efm.

I'm also running 👇 on the on_attach for tsserver which enables the eslint actions:

ts_utils.setup({
    enable_import_on_completion = true,
    eslint_bin = "eslint_d",
    filter_out_diagnostics_by_code = {}
})
ts_utils.setup_client(client)

It works but I dislike that there's a overlap here. I would prefer it if I would be able to just add eslint action handling straight to null-ls instead.

[jose-elias-alvarez]

There's a few reasons for the inconsistency:

1. nvim-lsp-ts-utils existed before null-ls and used a primitive version of the same mechanisms for ESLint diagnostics, code actions, and formatting. I eventually integrated it fully with null-ls and refactored diagnostics and formatting to be more or less independent, and the option you chose (separately registering those sources via the null-ls API) is definitely the recommended approach.
2. nvim-lsp-ts-utils is supposed to be an out-of-the-box solution to get up and running with TypeScript development in Neovim, so the goal was to make setup as easy as possible.
3. My hope was (and still is!) for other plugins, especially language-specific ones, to integrate with null-ls instead of having every source as a built-in (i.e. included in this repo). ESLint code actions take up about 150 lines of code, which isn't massive but is larger than any other built-in.

It's definitely possible to refactor the ESLint code actions module and allow direct registration via null-ls, but code actions are enabled by default if null-ls is detected, so I'd have to break existing configs to avoid double registration. I'm happy to consider other suggestions to improve the situation.

[sQVe]

Thank you for taking you time to answer me so thoroughly @jose-elias-alvarez!

I fully understand the issue with backward compatibility and breaking the setup for users. Still, the fact that I need to install nvim-lsp-ts-utils just to enable eslint actions is a bit of a bummer. Especially since I only need the actions part and that, I personally feel, the null-ls AP is superior in many ways.

Also - thank you for all your hard work with this 🙏🏼 It's been super helpful for me and simplifed my config greatly (used efm before).