Project architecture to support plugins

[alanz]

We have taken the same approach to plugins we had in haskell-ide-engine, with the same intention.

1. We have a plugin descriptor which defines the operations provided by the plugin
2. This descriptor is given a "label" when it is configured in exe/Main.hs, which serves to uniquely identify it within the particular set of plugins configured in that Main.hs, and thus the built hls executable.

This allows us to contemplate the next step wrt plugins

I propose the we split hls up

• a slimmed-down core, that basically corresponds to the plugins built into ghcide.
• an API package that can be used by plugin authors to write plugins for use in hls. The corresponds to the hie-plugin-api as originally envisaged.
• a fat package that depends on the core, the api, and all known plugins at this time, and provides an exe depending on them.

The fat module is the equivalent of what hls is today.

The intention is to facilitate two things, much the way LSP does for servers and clients

• tool authors can provide a module exposing an hls plugin API for their tool, built against the API module. e.g. a package fourmolu-hls could expose a plugin descriptor for fourmolou.
• users can choose which plugins they actually want to use, and not pay the compilation tax for ones they are not interested in.

To make this work cleanly, we could provide a utility that would take a descriptor file listing the plugin packages and the names to be used for them, and generate an appropriate exe/Main.hs.

And of course the existing Main.hs would have to be slimmed down to hosting a plugin config section and then invoking something in a library.

[pepeiborra]

I wanted the same thing when I was working on my retrie plugin.

One thought: since plugins need to access the ghcide internals as well, hls-core should probably reexport those.

Slimming down Main.hs is currently blocked by ghcide, but there's already an issue in the ghcide tracker to discuss that.

[alanz]

Slimming down Main.hs is currently blocked by ghcide, but there's already an issue in the ghcide tracker to discuss that.

https://github.com/digital-asset/ghcide/issues/478, I think.

[jneira]

Afaiu, after #379 the part that would remain would be

we could provide a utility that would take a descriptor file listing the plugin packages and the names to be used for them, and generate an appropriate exe/Main.hs.

[alanz]

I think a validating step would be to make a PR on an upstream such as one of the formatters, to include the plugin descriptor in it. This will help us to fine tune the API for the hls-plugin-api, by proving it in real life.

[jneira]

Issues related to complete the architecture:

• code organization: Create hls-plugin-api and move plugins to exe #379, Split HLS plugins into internal libraries #421
• plugins specific config: Regularise the config for plugins #513
• test infrastructure: Test infrastructure for plugins #576