Keep explicit support for non-lspconfig setup

[marcelbeumer]

Hi @jose-elias-alvarez, thanks for your work on typescript.nvim (and nvim-lsp-ts-utils before)!

I have a feature request.

I'm not using lspconfig. Instead I do vim.lsp.start inside a FileType autocommand myself (https://github.com/marcelbeumer/nvim-config/blob/e449f80d1e1a4e92ab4008d6ec392a9fe4345c29/lua/conf/lsp/server/tsserver.lua).

By reading through the source I've managed to using typescript.nvim by doing the same as your lsp.lua does:

-- once
require("typescript/config").setupConfig({})

vim.api.nvim_create_autocmd("FileType", {
-- ...
      vim.lsp.start({
        -- ...
        handlers = vim.tbl_extend("force", util.get_handlers(), {
          ["_typescript.rename"] = require("typescript/handlers").renameHandler,
        }),
        -- ..
        on_attach = function(client, bufnr)
          -- ...

          if not require("typescript/config").config.disable_commands then
            require("typescript/commands").setupCommands(bufnr)
          end
        end,

This seems to work fine but of course the risk is that things break later as I'm poking in typescript.nvim internals.

Would it be possible to keep explicit support for such a non-lspconfig setup, by adding instructions to the README, and then making sure things keep working? And in case of breaking changes update the README and preferably mark commit as breaking change?

Thanks in advance!

[jose-elias-alvarez]

Sure, I'm in support of this (I tried to do something similar in #30). I'd be open to a PR that either documents the process or even some kind of helper to set this up with a little less boilerplate, if you're interested.

[marcelbeumer]

Great! Yes, I'll follow up!