Deprecating ElixirSense module and providers

[lukaszsamson]

I came to a conclusion that keeping most of the provider logic in elixir_sense is hindering development of elixir-ls. It leads to code duplication, ineffective patterns (e.g. parsing the same file multiple times during one request handling). It also makes experimenting with new features difficult as we need to change two codebases and think about maintaining compatibility in a blackbox interface that no package besides elixir-ls is depending on. It is also difficult for new contributors as they generally don't know where to raport issues and how to debug language server.
My intention is to deprecate and completely remove most of ElixirSense module functions and provider modules, move that functionality to elixir-ls and leave elixir_sense as a smaller, more focused library providing building blocks only (source parsing, runtime introspection etc)

[axelson]

So is the proposal to archive this repo and move all the relevant code into ElixirLS proper? I'm fine with that 👍

[msaraiva]

I'm fine with that too.

I always said that ElixirSense shouldn't exist at all! Ideally, Elixir itself should provide those features as the compiler already does most of the work we had to reimplement (sometimes for many different versions). I have no doubt that some of the nasty issues we have can only be fixed when Elixir provides a minimal built-in/official language server as it's done in other languages like Go and Rust.

ElixirLS already seems to me as bloated as it can so it's a bit sad that we're moving the features on the opposite direction (ElixirLS <- ElixirSense as opposed to ElixirSense -> Elixir), but I understand it will lead to a better DX so feel free to move on.

As a final note, a lot of the initial work to provide a low level API for a future built-n LS has already been done in Elixir. It looks great and we already started to use it in ElixirSense. I'm not sure how much effort it would take to get to that minimal version of the LS, but in case theres already a clear plan from the core team to get there, we should probably talk to @josevalim and see if we could help with this task and concentrate our efforts in that direction. As I said, I believe this is the only way to get something with the stability and maintainability we want.

I remember that, not long ago, I read somewhere that editor integration was one of the major frustrations for developers when using Elixir and I agree with that. It's also frustrating for us, as ElixirSense/ElixirLS maintainers, since we may spend more time fixing compatibility issues across multiple versions than adding higher-level features that could actually improve user's DX.

ElixirSense already achieved its goal which was to provide the most common features users expect for an editor, in a time when Elixir was not mature enough. That's not the case anymore. At some point we'll need to do this the right way. The sooner the better, IMO.

[josevalim]

Making ElixirSense smaller may actually help get features into Elixir, exactly because it will have a smaller surface. We are still very open to increment and improve Elixir’s introspection APIs.

[msaraiva]

That makes sense. On the other hand, if the intention is to improve development of elixir-ls, I guess it's better to just move everything there and archive ElixirSense. After all, why bother keeping the two projects in sync when we can just have everything in the one place? The initial idea of ElixirSense as a separate lib was to allow other languages servers and tools to use it. If that's not the case anymore, let's just merge it and make things simpler.

We can try to keep things we believe belong to Elixir on isolated modules to make it easier to eventually replace them with a future official API.

@lukaszsamson feel free to transfer the code you need to elixir-ls and archive ElixirSense. Since it's under a MIT license, I believe you can just move the code the way it is. Let me know if you need anything.