Add support for running Rails generators from the UI
Motivation
This PR adds a Rails class to our VS Code extension capable of running generators from the UI. This is useful on its own, but it is also necessary for other functionality that may want to invoke generators programatically.
Implementation
I split the work into two commits:
- Add the
Railsclass with agenerateanddestroycommand and associate both with commands - Expose a
Ruby file operationscommand, where we can aggregate all of these under the same menu item. Then expose it in the explorer title and menu context
Automated Tests
Added tests.
Manual Tests
- Start the extension on this branch
- Open a Rails app
- Click on the new button in the explorer title view
- Use the generator
- Verify that it executes the Rails generator properly
https://github.com/Shopify/ruby-lsp/assets/18742907/ed13018d-4edd-4202-9a4f-d2aece96cacc
Similar to what @st0012 mentioned, it is a bit awkward that we'll be showing these commands for non-Rails codebases, especially if we add more Rails commands in future.
I'm looking at the available things we can do in the when of the command to conditionally display it, maybe we can come up with a creative solution:
https://code.visualstudio.com/api/references/when-clause-contexts
When generate a resource, it fails at the file opening stage for one file, I suspect the output parsing needs little adjustment:
cannot open file:///Users/andyw8/src/github.com/Shopify/ruby-lsp-rails/app/views/widgets. Detail: Unable to read file '/Users/andyw8/src/github.com/Shopify/ruby-lsp-rails/app/views/widgets' (Error: Unable to read file '/Users/andyw8/src/github.com/Shopify/ruby-lsp-rails/app/views/widgets' that is actually a directory)
I thought that if you try run a generator where some files already exist, Rails would interactively prompt to ask whether to overwrite each file, but I can't seem to trigger it. Maybe the behaviour changed in a more recent Rails version.
When generate a resource, it fails at the file opening stage for one file, I suspect the output parsing needs little adjustment:
Fixed it! Thanks for pointing that out.
Regarding not showing the button, that will become pretty complex given that you could have one workspace that is a Rails app and another one that isn't. There's no when clause that will tell you which workspace explorer view you are hovering over as far as I know.
So I propose we do something different. We always show the button, but then hide the Rails commands if the workspace is not a Rails app (which is significantly more straight forward).
To start out, so that we don't show an empty quick pick to users, I can follow up with a PR to add a New Ruby class/module file action, which essentially creates a new file with the entity selected.
This is common in IDEs, so it would be a nice feature to have and then we can move forward with a much simpler approach that won't require trying to figure out which workspace folder is being hovered over.
Thoughts?
When generate a resource, it fails at the file opening stage for one file, I suspect the output parsing needs little adjustment:
Fixed it! Thanks for pointing that out.
Regarding not showing the button, that will become pretty complex given that you could have one workspace that is a Rails app and another one that isn't. There's no when clause that will tell you which workspace explorer view you are hovering over as far as I know.
So I propose we do something different. We always show the button, but then hide the Rails commands if the workspace is not a Rails app (which is significantly more straight forward).
To start out, so that we don't show an empty quick pick to users, I can follow up with a PR to add a
New Ruby class/modulefile action, which essentially creates a new file with the entity selected.This is common in IDEs, so it would be a nice feature to have and then we can move forward with a much simpler approach that won't require trying to figure out which workspace folder is being hovered over.
Thoughts?
Yes, let's look into this in a followup.