Allow detecting Solidus components through a Rails setting

[waiting-for-dev]

This allows us to define solidus components at the application level, in contrast to the typical engine definition.

Components paths are loaded on an initializer, which runs before the application code that could define an Engine class. Adding a setting on the application.rb, which runs before the initializers, helps us working around it.

For now, we keep the old detection mechanism, as the other extensions will need to adapt to it first.

References nebulab/solidus_starter_frontend#162

[aldesantis]

I like the actual solution, but I'm opposed to the fundamental idea that we should allow people to run the frontends as a regular Rails engine. I left my thoughts here.

[waiting-for-dev]

I like the actual solution, but I'm opposed to the fundamental idea that we should allow people to run the frontends as a regular Rails engine. I left my thoughts here.

Hey @aldesantis. In fact, what this change is allowing is the installation of an engine including SolidusSupport::EngineExtensions (like solidus_auth_devise), into a solidus component present at the application level (like solidus_starter_frontend when it's installed by copying everything) :slightly_smiling_face:

[aldesantis]

@waiting-for-dev yep, that makes sense, although I think solidus_auth_devise should also provide its frontend code in the form of a generator rather than injecting it at runtime. What are your thoughts on that?

[jarednorman]

I don't know what a transition to that world looks like, but that definitely sounds appealing. Giving users an easy installation method but full control once they've installed everything would be amazing.

[waiting-for-dev]

@waiting-for-dev yep, that makes sense, although I think solidus_auth_devise should also provide its frontend code in the form of a generator rather than injecting it at runtime. What are your thoughts on that?

I completely agree, both for the frontend and the backend. I even suggested breaking it into components and including them in the solidus_frontend, solidus_core & solidus_backend gems. However, if that's the way all the extensions are organized, it probably doesn't make sense to bloat the main components. So, yeah, we could keep a couple of generators within the solidus_auth_devise gem.

The question becomes how we build the gem. I think these options may apply to other extensions, too:

• If the extension doesn't need to hook into the Rails.application, users can download the gem, execute the generators and uninstall the gem.
• If the extension needs to hook into the Rails.application, users need to add the extension to the Gemfile to run the generators. If the Rails context is only needed during the generation step, they could remove it afterward.
• We can consider doing the above process automatically from the main components. For instance, a generator on solidus_core could automatically do one of the previous steps.

[aldesantis]

@waiting-for-dev I think solidus_auth_devise will still need to be installed as a Rails engine because it provides the Spree::User model, and I don't think it would be a good idea to simply copy-paste that into the host app.

For everything else, though, we should just provide a generator.

[waiting-for-dev]

I think we can close this one, as it's no longer needed given the direction taken in solidus_starter_frontend (the auth code is also generated). cc @gsmendoza