search

rome / tools

Unified developer tools for JavaScript, TypeScript, and the web
https://docs.rome.tools/
MIT License
23.76k stars 664 forks source link

☂️ Editor Support #2390

Closed NicholasLYang closed 1 year ago

NicholasLYang commented 2 years ago

Description

Rome should work with more editors than VSCode. Because we use the language server protocol (LSP), it should be relatively easy to get Rome working with any editor that has an LSP client. All that's left is to document the process and make it easy to find the server binary. For editors that have poor LSP support like IntelliJ, we don't have the expertise to write a plugin, but perhaps someone sufficiently motivated could tackle it?

We should also document the fact that we use an LSP so that people know they can use an LSP client.

Poll

Related poll https://github.com/rome/tools/discussions/3544

Building an new integration

Adding support for a new editor should be straightforward for all editors supporting the LSP. Rome ships with a lsp-proxy command to which any editor can connect to.

JetBrain IDEs

Visit the relevant issue to upvote the ticket.

mattmarcello commented 2 years ago

If you could point me in the right direction, I would be happy to try to get vim (neovim) support working and documented.

ematipico commented 2 years ago

If you could point me in the right direction, I would be happy to try to get vim (neovim) support working and documented.

Thank you! Unfortunately the team doesn't have enough knowledge to help you out. Meaning we don't know how to make plugins for the listed editors.

One thing though, is that we'd favour plugins that use the LSP protocol.

I found this example on GitHub, maybe it can help: https://github.com/MunifTanjim/eslint.nvim

MichaReiser commented 2 years ago

If you could point me in the right direction, I would be happy to try to get vim (neovim) support working and documented.

Hey @mattmarcello We aren't familiar with how to write and bundle vim plugins.

The most straightforward implementation would be if vim (natively or through a plugin) supports the LSP protocol which we already use for our VS Code plugin.

@leops which binary and what's the command to start Rome in the LSP mode?

Feel free to ping us on this issue or join our discord channel.

Edit: Some links that I gathered a while back. One option is to fork prettier's or another formatter's plugin. This has the downside that other commands like linting wouldn't be supported out of the box. Or we use an lsp plugin instead:

Other formatter plugins

LSP Plugins

IWANABETHATGUY commented 2 years ago

I could help for writing documentation about neovim plugin

mattmarcello commented 2 years ago

I'm on vacation for a few days but I'll try to dig into this if I have sometime next week. Thanks for the resources.

leops commented 2 years ago

@leops which binary and what's the command to start Rome in the LSP mode?

Currently the binary that needs to be spawned is rome_bin with the argument __print_socket, but once #3143 is merged the binary will be rome_cli (I'm going to remove the daemon prefix from the PR so the command will still be __print_socket for now). This command will make the CLI print the "address" of an OS-specific socket (domain socket on Unix, named pipe on Windows) the Language Client can connect to.

IWANABETHATGUY commented 2 years ago

I am not a guru of nvim, here is a nvim config that has the same functionality as vscode extension in the latest rome (v0.9.2-next) (lint, formatter) https://github.com/rome/tools/discussions/2131#discussioncomment-3620044

alecandido commented 1 year ago

In principle, coc.nvim is a lsp client plugin for (neo)vim running on NodeJS, such that it should make plugins as similar as possible to VSCode once, citing them:

Make your Vim/Neovim as smart as VSCode.

I guess useful resources should be:

antonk52 commented 1 year ago

If you want to have support in vim/neovim I strongly recommend not to lean in towards a single LSP client plugin like coc.nvim. Instead if you have a standalone LSP executable it can be used by both vim/neovim and other terminal based text editors(emacs)as well as it could also be plugged into coc.nvim.

Picking coc.nvim significantly lowers a percentage of vim/neovim users who would be willing to switch to or include coc.nvim for Rome alone.

An example how a single LSP client can be enabled for both neovim with lspconfig and coc.nvim

strager commented 1 year ago

@antonk52 I think @AleCandido was not suggesting that Rome only support coc.nvim. Rather, coc.nvim is one ecosystem which Rome could plug into and support.

coc.nvim might be the easiest for Rome to integrate with (in terms of engineering time) because Rome already has a working and maintained Visual Studio Code extension.

alecandido commented 1 year ago

@strager thanks, that's what I thought. I believe @antonk52 was just suggesting to broaden the audience: since coc.nvim is just another LSP client, you can support more vim/neovim's clients, more or less with the same approach, and it makes sense.

However, even if I was asking to support coc.nvim as a generic "support a LSP client for vim/neovim", now I'd stress slightly more the coc.nvim proposal. While for VSCode there is a single client, for vim/neovim there is not a unique one (coc.nvim, nvim-lspconfig, vim-lsp, ale, LanguageClient-neovim). So, you can provide plugins for all of them. Or you can give instructions to set them up, given a unique server wrapper (I believe for Rome would be a bit more difficult then cssmodules, but I might be wrong). But I would suggest to start with one, and coc.nvim is a good candidate, just because in my experience is the most popular, but whoever will start of course will pick his favorite ^^

Of course, after the first it should be possible to keep going with the others. But, in a sense, I expect the second to be as complicate as the first one, since the server already exists.

lucafanselau commented 1 year ago

Hi there, I am considering adding a third party emacs plugin. Is the overall plan for the lsp_proxy mode to support autocomplete down the line? As the lsp client that is going to be merged into emacs (eglot) (at least to my knowledge) only supports a single running server per buffer, i guess that use case would only be interesting if rome would be able to (in the future) completely replace tsserver. The alternative would be lsp mode (which provides an addon server mode), but as I am currently not using that plugin I would be more interested in the eglot use case.

MichaReiser commented 1 year ago

Hi there, I am considering adding a third party emacs plugin.

We want to look into adding support for more editors in the near future. You can help us prioritize by voting for your preferred editor here.

Is the overall plan for the lsp_proxy mode to support autocomplete down the line?

Adding more capabilities like autocomplete is something we want to do but it may take a while until we have time to implement it.

fannheyward commented 1 year ago

https://github.com/fannheyward/coc-rome was born two years ago with TypeScript-based Rome support, and has added the new RIIR Rome supports.

marekpiechut commented 1 year ago

Hi, I've created a Rome formatter plugin for SublimeText here: https://github.com/marekpiechut/sublime-rome-formatter

Should show up in Package Control when it's approved.

edit: Plugin is now live in Package Control so you can install it directly from Sublime

rchl commented 1 year ago

I'm also working on LSP-based package for Sublime Text - https://github.com/sublimelsp/LSP-rome/pull/1

Compared to the above package, it will provide full integration including formatter, linter and code actions/refactoring support.