haskell / haskell/haskell-language-server

Document architecture and relationship between component projects

Ouverte
#409 21 commentaires 7 réactions 0 personnes assignées Voir sur GitHub
type: bug type: enhancement
Langage dominant
Haskell
Étoiles
3k
Forks
455
Merge moyen
2 j 19 h
PR mergées (30 j)
11

Description

I think one of the barriers to new contributors such as myself on this project is understanding the suite of disparate tools that come together to make HLS a reality. I think guiding early users of HLS towards being able to hack out solutions to bugs they discover or know **where** a feature they want might go can go a long ways towards creating a self sustaining (and growing) project.

At present, as a pre-first time contributor (but attentive user), the questions that come to mind are these:

- What is the relationship between `hls`, `ghcide`, `haskell-lsp`, `hie-bios` etc? How do they fit together?
- Are there any component projects not mentioned in the list above that I am missing?
- When I want to open an issue, fix a bug, or add a feature, how should I go about reasoning which of these 4(+?) codebases that the change belongs in?
- Is the partitioning on these lines **essential** or a historical accident?
- Is their partitioning presently beneficial to the project? If not, what barriers exist to merging them, if any besides the fact that it hasn't been done yet?

I open this issue as a way for me to start trying to contribute to tools in the best way I know how, which begins with some documentation on the architecture of hls.

I want to end with an anecdote about why I think this is important.

A few weeks ago I noticed #342 and opened an issue for it. It seems like something that was going to be within my grasp to fix, but the rabbit hole got deep fast. I was pointed to `ghcide` as the source of the problem, which in turn seemed to point to the idea that the problem was in `haskell-lsp` (yet another project I had not heard of). At this point I lost confidence in my ability to help the situation. It turned out alright as it looks like the issue was fixed in the last few days, but I can't help but think that the project would be better off if people such as myself were able to guide themselves quickly to the place where they could hack on things that weren't 100% local to the `hls` repo itself.

TL;DR If you have any information on the architecture of `hls` either by links to blog posts or know-how inside your head, drop them in this thread and I will try to compile them into a document inside this repository.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.