Hey guys, fairly new to Haskell and I’ve been fighting an issue where when I add a package to a .cabal file and build the application I will get an error that VScode can’t find the module.
I’m currently in the top level folder and can view the .cabal file. I can successfully build the project using cabal build and when I close and reload VScode it can then resolve the module.
I would expect that VSCode should be able to resolve these on the fly. Any ideas where to go?
As far as I know, when you change the cabal file you have to restart HLS (not all of VS Code, just HLS). That used to be the way, at least. I don’t know if it’s changed in more recent versions.
HLS should restart things correctly if the cabal file changes, so I doubt it’s that.
Do you have a cabal.project file? If not, HLS may be confused about how to build the project and you might need a hie.yaml. See Configuration — haskell-language-server 2.4.0.0 documentation
It also might be good to check if you’re running the latest version of HLS. I believe some older versions did not restart things on cabal file changes.
Yeah I’m still using 1.7.0.0 (for some reason) and that doesn’t seem to restart on .cabal file change. (I appreciate that’s really old – I guess I should upgrade, but it mostly works so I’m scared to touch it …)
What may be needed is to force HLS to reparse the current file. Like adding a space and saving, this works for me (with a cabal.project and a hie.yaml and the most recent cabal, HLS and VS Code plugin versions).
Hello all, first of all thanks so much for the feedback. @tomjaguarpaw, you are correct I only need to restart HLS, which is a bit better but still takes about 60 seconds to get up and running. I decided to create a new project for a blank slate and the behavior is repeatable. I created a basic cabal project using cabal init.I then created an hie.yaml using gen-hie.exe.
I’m a little unclear on the need for a cabal.project file. Also, what should go into this? I verified that I’m running HLS 2.4.0.0 installed through ghcup and the latest version of the extension.
Thanks!
Notice hls will rebuild your project. Hence, if you add a dependency is very likely that hls will download and build that dependency and all transitive dependencies too, which might take a while. The amount of time depends on external factors. For example, if you have download that dependency before (for example, in other project) it should be faster, but still not super fast, also, if you change your compiler version in the middle of a project development, then you (cabal or hls) must re-download and re-build every dependency.
What I mean is that taking 60 seconds to be responsive after modifying the cabal file can be very regular behaviour, so don’t overthink it too much. Btw, the hie.yaml can be a simple
cradle:
cabal:
for regular projects, but it is ok to use gen-hie too. The cabal.project file is meant to be use when you have more than one package and fine grained control over the build parameters… which I don’t think is your case 
Really? I haven’t written a hie.yaml file for at least two years at this point, and I thought they were only needed for pretty bespoke setups. I’ve certainly used HLS on a Cabal package without a cabal.project and not had any issues.
tl;dr I’d be disappointed if a trivial hie.yaml still makes any difference to anything
It does, but not a trivial one like
cradle:
cabal:
Without one I did get more (or any) flaky ‘hidden package’ errors from HLS, errors where a restart of HLS made them go away. And I’m talking about a simple project with one executable, a library and tests.
So if you have any errors with HLS, but not when building “normally”, adding an explicit hie.yaml did always help - at least for me.
The hie.yaml addtion doesn’t seem to change the behavior at all. I suppose the manual restart of HLS isn’t the end of the world. Through VSCode you can map it or just ctrl-shift-P. I’m curious how this scales with large projects.
I set up Neovim with HLS as an experiment and it seemed to work as expected. Cabal files were being indexed when updated.
In my experience the easiest and quickest way to make HLS “wake up and smell the roses” is to hit ctrl+shift+p → “reload window”. This will restart all extensions including HLS.
The most common reason that HLS is unable to figure out your project is when the root of the project is not opened as a folder in vscode, but either some containing folder is opened or only specific files within it. The name of the folder should appear at the top of the first Explorer tab, like this:
and once that is done HLS should activate in the normal way. (I say should; HLS has been rapidly becoming more robust and stable but there’s still a ways to go before it’s 100%)
I’ve just tried something similar. When removing a used (but still installed) package from the PROJECT.cabal file, HLS error-squiggles the open with the “hidden package” error after a short delay (some seconds). Putting it back into the .cabal files resolves the error after a short delay too - without me doing anything.
The behaviour does not change with or without a hie.yaml.
But when opening a subdirectory of a project and changing the PROJECT.cabal file, you do have to restart the extension to recognise the change (displaying or removing the error).
My suggestion about the hie.yaml was just in case we don’t cope well with standalone cabal packages, but apparently we do, so that’s good!
Can someone make an issue about changing cabal files not invalidating the build, ideally with a reproduction? I’m pretty sure that used to work, I do it a lot and I never have to restart HLS.