Support Rails auto-detection for engines/railties

[rhysb27]

I have checked that this feature is not already implemented

• [x] This feature does not exist

Use case

The LSP currently does not auto-detect Rails for Engine/Railtie projects, presumably as of #2218. The ability to use the Rails add-on when working on such projects would be extremely useful, particularly for tests and feature congruence when working on Rails applications and common dependencies simultaneously.

Description

A few options come to mind:

1. The Rails LSP add-on to be automatically installed upon detection of a Railtie-based project, instead of just a concrete application
2. Automatic inclusion upon detection of a Rails dummy application
3. Manual configuration via VS Code Settings to "tell" Ruby LSP to install the add-on

Implementation

Ideally the auto-detection for Rails apps would be modified to add an additional check - whether or not the main class descends from Rails::Railtie. Variable-depth namespacing may add complexity to finding the main class, but I'm no expert. Applying the current check a second time at [spec|test]/*/config/application.rb may be a suitable alternative for basing inclusion on the existence of a dummy app - something included as standard by the Rails plugin generator.

If these options aren't feasible, could some mechanism be added to allow users to manually specify that the Rails add-on should be included?

[andyw8]

Potentially related: https://github.com/Shopify/ruby-lsp-rails/issues/221

[vinistock]

Thank you for the feature suggestion! Indeed, we should provide the same features for engines. Is there anything mandatory about the structure of engines or some convention we can rely on?

For example, is it mandatory/recommended to have a lib/my_gem/engine.rb with something that inherits from Rails::Engine?

I think automated detection is the way to go here, we just need to ensure that we're accurate about detection.

[andyw8]

The Spree gem may be good to be good example to verify against as it contains multiple engines.

[rhysb27]

Is there anything mandatory about the structure of engines or some convention we can rely on?

For example, is it mandatory/recommended to have a lib/my_gem/engine.rb with something that inherits from Rails::Engine?

@vinistock thanks for the interest! As far as I'm aware, any engine or "simple" plugin that hooks into the Rails initialisation timeline (and thus is likely tested via a dummy app as per the plugin generator) does so via a core class which descends from Rails::Railtie. Engines add an extra layer but Engine's parent is still Railtie. Using this as an automatic detection rule seems sound, at least to me. @andyw8 rightfully points out that some more complex projects may have multiple engines/railties but as long as at least one is present, it would be unusual for the project to not benefit from the Rails add-on.

As mentioned though, plugins/engines may be arbitrarily namespaced. The standard/generated railtie location for a single-depth namespace is indeed lib/my_gem/[engine|railtie].rb, but lib/my/gem/[engine|railtie].rb would also be valid. I suspect as long as the file a) descends from Railtie and b) is exposed to the installer, the location and filepath can be completely arbitrary, but given Rail's philosophy of convention over configuration the above base cases should satisfy the majority of cases without introducing unreasonable false positives.

[nickpoorman]

I think at the very least it would be nice if ruby-lsp supported development of engines. You can easily create a new rails engine to test this via: bundle exec rails plugin new my_engine --mountable. You will see a test/dummy directory created. The convention is usually to run the test/dummy as the application since the engine does not have one itself.

bundle exec rails plugin new my_engine --mountable
cd my_engine/test/dummy
bin/rails server

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months