Support projects in subfolders

[ColonelPhantom]

Is your feature request related to a problem? Please describe.

I'm currently working on a project of which a Haskell project is only a small part. When trying to open the root folder in VSCode however, the Haskell extension does not pick up on the Stack project in the Haskell-specific subfolder.

Describe the solution you'd like

I would like the extension to select the Haskell project folder by looking for stack.yaml/*.cabal/whatever files, instead of just naively picking the opened folder as Haskell project folder.

This is also what Kate does, its LSP client default configuration has the following line for HLS: "rootIndicationFileNames": ["*.cabal", "stack.yaml", "cabal.project", "package.yaml"]

Describe alternatives you've considered

• Just open the Haskell project in a separate VSCode window, and have two windows open (kind of annoying imo)
• Allow creating a file that instructs HLS where to actually find the project (a bit hacky, but would be a decent workaround)
• Open both toplevel and projects in a multi-root workspace

Additional context

Consider the following folder layout:

toplevel
| - project
| | - stack.yaml, project.cabal, src/, all other parts of a Haskell project
| - otherStuff

In my example, I open toplevel in VSCode (instead of project), but want HLS to use project as root folder.

So if I open the file project/src/Main.hs, I want HLS to start with Directory: toplevel/project, not Directory: toplevel which causes it to miss the stack/cabal files that allow it to know what dependencies I am using etc.

[fendor]

Hi, thank you for the feature requests! The requested feature looks sensible to me, but it feels like it is easy to get wrong.

Let's think about the use-cases and how we want HLS to behave.

We can think of a number of potential project structures:

1. Workspace is the project (current behaviour works perfectly fine)
2. Single Haskell files in a non-haskell project (cabal/stack scripts for example. See vscode-haskell/GenChangeLogs.hs for an example of such projects.)
3. Haskell project(s) that is/are a subset of a much larger project

•   root
    |_ haskell/
    |_ haskell2/ 
    |_ not-haskell/
  

4. A mix of 2. and 3.

We have the following requirements:

• All sub-projects/scripts have to use the same GHC version, as HLS needs to be compiled with exactly the same GHC version to function properly.
• We need to decide on which HLS version (including the GHC version) to launch before we actually build any of the projects / haskell files in the project.

VSCode gives us the URI of the filepath that caused the extension to be activated. Given that information, it should be rather trivial to figure out the GHC version required to build the haskell file.

~~I am not sure what I want to say with all of this, but it took me long enough to write down, so I am not deleting it :D The fix could be rather simple.~~

One issue we have is that we try to figure out the GHC version to compile the project, but HLS also tries to figure out the GHC version on its own which would likely fail for us.

[ColonelPhantom]

All sub-projects/scripts have to use the same GHC version, as HLS needs to be compiled with exactly the same GHC version to function properly.

Is there any requirement for the plugin to launch only a single HLS instance? It doesn't sound unreasonable to me to run one HLS instance per subproject, although that does of course have drawbacks like much more memory usage.

[fendor]

Is there any requirement for the plugin to launch only a single HLS instance?

I am not sure, but usually, if you have a project, you often have dependencies between haskell packages. If you launched different HLS instances per subproject, HLS would likely get confused.

[georgefst]

This would be great. I've seen it trip up beginners a few times. And I actually have at least one project which has a cabal.project at the root for this sole reason.

For some reason I always assumed the fix would be difficult.

[fendor]

For some reason I always assumed the fix would be difficult.

We are not sure, whether is difficult, quite easy, or perhaps even required by the lsp standard :)