Recently I’ve casually started working on a Ruby LSP add-on for Hanami. Initially, the main goal was just to have some way to click a dependency included with the Deps mixin, and go to it’s definition. I have that sort of working in a very ‘specific to a certain use case and likely only works 20% of the time’ sort of way (you know how these things go)
Emboldened with support from @cllns, I wanted to take a moment to pause and do some soliciting.
I’m wondering:
a) if this is an effort worth continuing, with the ultimate goal of adding to the Hanami DX landscape
b) what other features in a project like this would be valuable to the community
Regardless of outcome: I just wanted to share and do a general call-out for collaboration! I will likely (unless this post is met with extreme negativity, and even then, maybe) continue working on this project in some capacity, but want to advertise the rest of the world early. The goal is to build this for the community, so the community should have a say in its development.
This is absolutely worth continuing! Tim and I have talked for a while about building out an LSP, and it’s even mentioned on our sponsorship drive page: https://sponsor.hanamirb.org/ Having a solid LSP is basically a requirement in 2025, IMO. I think we’d like to pull it into the Hanami github org once it’s nearly ready for release, if you’re cool with that
I think ruby-lsp-hanami would be a better name for now, to match the convention other Ruby LSP addons have taken: Repository search results · GitHub This is contra the Rubygems naming guidelines, but it does look better IMO. Though if you’re cool with moving it to the hanami org, we may rename the repo (if not the gem) so it might not be worth the effort right now.
“Go to definition” is great! I think there are a couple more things we can do to help users:
Adding component keys to “document symbols”
Adding autocompletion when typing the keys in. Ensure these work for include Deps[], Hanami.app[], HelloWorld::App[] etc. i.e. all instances of Dry::System::Containers and injectors
Validating that a component key exists in the container (so show a message if the key doesn’t exist in the container, potentially with a DidYouMean-type message for typos?)
It makes sense to focus on Hanami at a high-level for this, but long-term (in true Hanami/dry-rb fashion) it’d be great if we could eventually make this work for all implementations of dry-system. But we don’t need to rush there, the conventions in Hanami can help us move quicker. We can extract them later.
One thing we have to keep in mind is that we need to support Slices as a primary use. So, our tests should include basic app usage, as well as slice usage (and ensuring it doesn’t get confused with identical keys in different contexts).
Beyond dry-system: there’s also some functionality I’ve thought about with connecting (1) controller and view, (2) view and template, (3) repos and relations/DB schema, but I think those could come later, once we get the dry-system LSP solid. At that point I imagine we’ll be like “oh! we could have the LSP help with ____”
happy to change the name to something more conventional. i’m also happy to transition to the hanami org whenever you’d like!
thanks for the detailed response. these are all excellent suggestions and exactly the sort of feedback i was looking for. currently ‘timeline’ is a little ambiguous, but at least now i know what direction to start going!
i agree that currently hanami is the big fish, and we have a fair bit of things that we can include at a hanami level that would make a lot of progress really quickly in terms of improving dx. that being said i do like your longer term vision of blurring the edges into dry-* gems. where this ends up, im not sure, but at least we’re beginng to start building a solid foundation!
i’ll occasionally update discord with any progress i make!
I’ve had colleagues say to me that they didn’t like using Container keys because it confused their IDE support, so I would be very interested in helping make this work.
I actually started a similar project last night without checking the forums first and got a basic proof of concept working with some code lens support for jumping from actions → view classes and actions → templates, which was an area I struggled with the first few days of Hanami for me and still struggle to get fuzzy finder to go to the right index.rb class file .
On my list was trying to get the Deps completion stuff worked out as a proof of concept and it looks like you may have got there first.
I have some general code that also would add the GET /about code lens that would jump to where it’s defined in a routes file too, but need some work on the framework end to support this.
One of those things is adding hanami runner to run a server instance like how ruby-lsp-rails does for Rails support for some of the more in-depth things that need the rails app to run for it other than the static analysis.
I’m probably going to continue hacking on this when I get some free time, but I think I’ll port in my work into the foundation you established and when something works it can probably be absorbed into the Hanami org if the core team / other maintainers agree / you’re ok with that.
In my mind critical things that would help me dev Hanami apps:
Code Lens
Jump to File Support for Action → View Class, Action → View Template, Action → Route with a little text for GET /about to show what route / verb points to the action.
In view classes → point to the action class / template too probably?
Completion
Dep keys for the containers in main app / slice etc. (I think this is working in the GitHub so far?)
Something around relations / repos / structs to help with completion of attributes / schema.
Running Actions / Commands (not sure what ruby-lsp-rails calls this?)
Quickly being able to run a generator in editor would help reduce context switching. ruby-lsp-rails does this for the generator iirc so perhaps we could learn from this approach too.
Test Runner
Code lens support / in editor test running for a file / single example / block of examples in rspec
probably more things could be doable too, but I feel like that’d get things 80% of the way to start.
In my parsing of the files for code lens I got some ideas for like oh request.params in controllers too, perhaps we could use the params block to help complete things, but hadn’t got that far in my ~2 hour spike/proof of concept work.
Anyway, great work on kicking off it with some code and discussion! I can’t wait to join in making something awesome for Hanami / Dry / Rom users.
@afomera Thank you! It sounds like you’ve made some amazing progress.
Your vision for where this can go is really inline with my long term ideas were as well. I’ve tried so many languages and frameworks and I feel like poor tooling immediately sticks in my head and is hard to get past. Since so many people will come to Hanami from a different framework () and potentially feel uneasy at first, I agree it’s super important to support developers as much as we can.
you’re also correct. I’ve been slowly picking at this in the background for a few weeks, but have basically exclusively focused on “Deps” things (autocomplete, click to definition, etc). Mostly because that was what I personally most desired in my work w/ Hanami.
I would love to join forces here if you’re open to it (p.s. to any future reader - all help welcomed!). You’ll certainly outpace me in terms of productivity (idk how you do it???) but getting this together would be a huge add to the ecosystem and I think we can do it. I will reach out via discord in the coming days to chat more (to not clutter this theead up).
.
) and potentially feel uneasy at first, I agree it’s super important to support developers as much as we can.
(p.s. to any future reader - all help welcomed!). You’ll certainly outpace me in terms of productivity (idk how you do it???) but getting this together would be a huge add to the ecosystem and I think we can do it. I will reach out via discord in the coming days to chat more (to not clutter this theead up).