Provide workspace configs for text editors

[FranjoMindek]

Currently, it takes a bit of configuration to get all tooling around wasp working.
Especially around Haskell whose tooling is less supported by text editors.

We should provide config files for often used text edits which would solve above problems.
e.g. .vscode for VSC

Even better if they could include recommendations for all extensions needed to work with wasp normally.
e.g. .vscode\extensions.json for VSC

This would solve issues around:

1. Which formatters to use (e.g. ormolu for Haskell, which is not default)
2. Setting up formatters (e.g. pointing to wasp's local ormolu binary)
3. Setting up right Haskell environment (e.g. use GHCup)
4. Wasp packages
   • e.g. wasp extension for VSC has wasp.server.executable which allows it to grab AppSpec from local development version of binary, which is necessary to test any AppSpec changes with wasp extension for VSC

TODO: any more issues solved by this?
TODO: which text editors to support? should each be it's own issue with this being an parent issue?

[cprecioso]

Related to #2736 (we can also add prettier formatting)

[cprecioso]

Formatters and environment are different problems though. I can't see us running GHCup inside a VS Code configuration right? (If it's even possible?)

[FranjoMindek]

More about pointing haskell to right binaries, since user might have multiple versions installed, and might not have our version in path as default.

e.g. .vscode

{
  "haskell.manageHLS": "GHCup",
  "haskell.toolchain": {
    "hls": "1.8.0.0"
  },
}

Users can always override these settings, if needed.

[cprecioso]

Users can always override these settings, if needed.

No, they can't though. If I modify my User preferences, the workspace ones will take precedence. If I modify the Workspace preferences, this will show up as a modified file in git.

[FranjoMindek]

That's what I meant, this configuration files should follow how we specify to set up the environment in our waspc readme.
Any deviation from that and you should not expect it to be set up for you.

If they are deviating I don't see it a problem that they have it as an modified file in git.

[cprecioso]

If they are deviating I don't see it a problem that they have it as an modified file in git.

I don't agree 😅 I think each environment's setup (especially if only related to a single IDE) is a local workstation concern and not one that should be stored in the repo (moreover if it's going to override my User preferences).

For reference I have my haskell setup through mise and not through GHCup. Git would keep bothering me to stash the config file or whatever.

[FranjoMindek]

That is a good point. How about limiting the scope to what is actually done on workspace level, rather than tampering with global configuration?
e.g. we always store ormolu binary we want to use in repo, so having that might be worthwhile?

[cprecioso]

My preference would be to not add any settings for the environment at all (e.g. ormolu), and just add those related to workflow (e.g. auto-formatting). If we can define the versions without setting paths for them, I'm also up for it.

[Martinsos]

I haven't read everything, I would just be careful that we don't spend too much time here on somethign that at the end won't work for everybody.

On one hand, having clear instructions in README on what to install is maybe the best -> they can follow that easily and all is good.

It will depend on the specifics of the implementation here, I am just saying, I wouldn't push this too far -> if we can get something very practical very easily, great, if not, manual instructions are probably good enough.