LSP Targeting multi product

IntelliJ Platform
1

Hi

I just finished implementing a feature with LSP4ij
But I am thinking of splitting the plugin so that I will release 1 version with this implementation targeting noncommercial IDE and implementing using the Jetbrains SLP infrastructure targeting commercial IDE.

Any suggestion on how to do it?
Should I create subprojects for each implementation or any other suggested approach?

I went over the documentation but not sure about the solution.

Thanks

2

Hey Jonathan!

LSP4IJ is open source product with lots of supported LSP specification features (methods).

Last time I touched JB LSP there were ~10 from more that 100 from the specification.

It’s all depends on LSP4IJ license, but I’d did all in combination and with freemium subscription: some features are free all the time, some features paid with or withoud trial period.

If you’re able to implement the missing features from JB LSP, then go on with JB LSP because it’s convenient to use compared with LSP4IJ

3

Hi @xepozz
Thanks for the reply.

My plugn’s lsp feature requirements are small and is not a matter of features but I am thinking more
from the user perspective that in non commercial IDE they will also have to install the lsp4ij plugin, and since I don’t want to make it mandatory of they don’t the lsp support is disabled.

Since the majority of the plugin users are Rider and Ultimate the Jetbrains lsp support will be available if I use that…

So this is why, I though on splitting the plugin into two…

4

I may wrong, but I thought if a user install a plugin, all dependencies will be installed automatically, right?

5

You can mark a dependency optional

6

So in this case the best way is to split the plugin: the one with required LSP4IJ and the other is about JB LSP integration

7

To speak from my own experience: publishing two similar plugins will not only take considerably more maintenance efforts but also cause much confusion for users.

It is possible to allow choosing between the two clients (I’m doing exactly that) with LSP4IJ being optional. But there’s a catch: The two clients cannot be both loaded in the same session. Most users will use the default settings, so it’s very unlikely this bug will be encountered by the average user.

Thus, I think the best possible solution is to:

  • Make LSP4IJ an optional dependency
  • If the native client is available, use that. Otherwise, notify the user that they need to install LSP4IJ and provide them a convenient way to do so (a notification action in the form of a button?).

Disclaimer: I never tried this approach, since in my case I have a third, “command line” mode as the default.

8

Thanks, @insyncwithfoo - yes having two similar plugins sounds complicated.

@yann.cebron @jakub.chrzanowski - is there an internal discussion at JetBrains to open LSP to all IDEs? any suggestions from your experience?

10

I can only recommend sticking to our API as we are sure it is much more performant and battle-tested than anything else. No plans to port it to Community edition so far. At the same time you may consult to your own plugin statistics about IDE usages and spot some patterns in paying users choices.