Add code lens for mapping actions to routes

[gmcgibbon]

Part of #50

Adds code lens to find routes in the routes file based on a given controller action. You need to grep bin/rails routes for this information manually. If Rails already knows this info, we should make it more easily accessible.

NOTE: This PR uses private API of Rails. I need to find a way to surface an endpoint in the Rails router to support this feature properly, if others agree it is useful.

[gmcgibbon]

It seems kind of silly to me that there's no native support in editors for a file opening command (that I can see). Is there a way around this, or should I proceed with my PR that implements this over on the extension? There's a 'editor.action.showReferences' command, but I can't seem to get the expected parameters to work using it. I also don't know if all LSP supported editors have this command available, or just vscode?

[rickcaudill]

I had a patch like this coming this week. I don't work for Shopify and have been really busy at work so I didn't have time to get the tests done yet, so I wasn't pushing it up.

The format I had for routes was:

        name: route.name,
        verb: route.verb,
        path: route.path.sub(/...format./, ""),
        controller: route.controller,
        action: route.action,
        source_location: "#{::Rails.application.root}/{route.source_location.sub(":", "#L")}",
        views: ActiveSupport::Inflector.safe_constantize((route.controller.to_s + "_controller").camelize).new.lookup_context.find_all("#{route.controller}/#{route.action}").map do |route|
                 { filename: route.identifier, format: route.format }
               end,
      }

If you use vscode.open, you can do this for VS Code at least.

If you want to do it all you could use just the uri for non vscode editors (but I haven't checked on how to do this yet).

My lens looked like:

[rickcaudill]

Can you please include the views as I have code action coming to open corresponding views?

[rickcaudill]

Also note, if you use #L#{line_number} you can jump to the right line.

[gmcgibbon]

View lookup was another feature I was thinking of too, but I didn't get that far. I was thinking it would be a separate code lens, and maybe an entirely different request to the rack app. I'll see if I have time to implement it over the next few weeks, but I can't promise anything right now.

I'm not directly part of the team maintaining this repo, so let's get their opinions in this patch and the views idea as well before we proceed. If we do end up using some of these ideas, I'll give you credit via co-author on what I commit.

[rickcaudill]

Either way I will be doing the views. I am trying to replicate most of Rubymine for my team so I will probably do an add-on if needed.

[rickcaudill]

Thanks for the co-authorship :)

[andyw8]

From looking at the spec, a Code Lens doesn't need to have a command associated with it, so we could ship this with only the label, and deal with the command behaviour in a follow-up PR.

[andyw8]

@rickcaudill thanks for those suggestions. I think we can handle it separately, so I've created #384 to track.

[gmcgibbon]

Looks like this is failing on HEAD, but I don't know why yet.

[andyw8]

This PR uses private API of Rails. I need to find a way to surface an endpoint in the Rails router to support this feature properly, if others agree it is useful.

When speaking with Jean and Aaron previously, they suggested that if necessary we can make modifications to Rails to expose an API for these kinds of things.

[andyw8]

(nit) could we return early here?

[andyw8]

👋 @gmcgibbon

I forgot about this when adding #331. There's a bit of commonality, so once that's merged we can hopefully rework this.

This PR uses private API of Rails.

Which aspect do you mean here?

[andyw8]

Updated due to the changes in main.

[andyw8]

@gmcgibbon I changed this from route to route_info to better distinguish it from route_location.

[andyw8]

Ah, I think i see what you mean about the private API usage now:

https://github.com/rails/rails/blob/705b70a2f1ccb2b1a330124f3e50c4b7f4b5f75f/actionpack/lib/action_dispatch/routing/route_set.rb#L15

[andyw8]

Possible change for Rails:
https://github.com/rails/rails/compare/main...andyw8:rails:andyw8/route-from-requirements?expand=1

[andyw8]

Not a blocker, but when testing on code-db I noticed a limitation:
For routes with a param defined, the code lens won't show because, e.g.
{:controller=>"projects", :action=>"update", :slug=>/[^\/]+(\/|%2F)[^\/]+/}
doesn't match
{:controller=>"projects", :action=>"update}

[andyw8]

From looking at the spec, a Code Lens doesn't need to have a command associated with it, so we could ship this with only the label, and deal with the command behaviour in a follow-up PR.

I've gone ahead and removed the command parts from here. We'll also need a small update to Ruby LSP: Shopify/ruby-lsp#2069

[andyw8]

Opened a PR for Rails: rails/rails#51850

[andyw8]

The Rails PR was merged, so I've updated the code to use the new from_requirements if available.

[andyw8]

The Ruby 3.0 failures will gone with #391

[andyw8]

From looking at the spec, a Code Lens doesn't need to have a command associated with it, so we could ship this with only the label, and deal with the command behaviour in a follow-up PR.

Change of plan: Shopify/ruby-lsp#2102