Add lib/controllers/ENGINE to the autoload_paths

[DanielePalombo]

Summary

SolidusSupport added lib/decorators/#{engine} to the autoload_paths, but there are no other autoloaded_paths for lib. This is a problem when the decorator tries to decorate an existing class, because it's not loaded yet.

A real example, happened on solidus_social, because it decorates a controller defined on solidus_auth_devise.

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• [x] I have written a thorough PR description.
• [x] I have kept my commits small and atomic.
• [x] I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[DanielePalombo]

@elia, this is the ticket we have investigated today.

[kennyadsl]

@DanielePalombo I'm not sure to understand the problem: are you decorating a controller that has been defined in the same engine? I'm sure I'm missing something, can you make a rough example?

[elia]

@kennyadsl as a result of the investigation we discovered that with Rails 5.2 and Solidus 3 the RegistrationController defined by solidus_auth_devise was not autoloaded correctly and another extension (solidus_social) attempting to decorate that controller was not finding it.

The decorator paths were added to the autoload paths here but the same wasn't done for lib/controllers.

[kennyadsl]

Ah, so, so we are talking about decorating controllers defined in other extensions, which are not autoloaded, makes sense now!

[DanielePalombo]

Thank you @elia for the explaination

[kennyadsl]

Merged, do we need a new version released?

[DanielePalombo]

Yes, please!

[kennyadsl]

@DanielePalombo @elia done!