Eager loading view_components fails when app/components is set as stories_path

[seand7565]

Test app here, details in the readme: https://github.com/seand7565/view_component_storybook_autoload_bug

We have app/components set as our stories path, so a components stories can live with the component that it renders.

However, this causes a devious bug that prevents anything in app/components from eager loading, causing some mayhem when an app is first launched.

We set our stories_path the same way it's set in this gem - as a Pathname object:
Rails.application.config.view_component_storybook.stories_path = Rails.root.join("app/components")
which generates this: #<Pathname:/#{path_to_app}/cometeer/app/components>.

However, Rails adds app/components to eager and auto load as a string and not a Pathname object. (I'm assuming this functionality is coming from Rails, anyway).

So the order of operations is:

• Rails adds app/components to eager and autoload.
• Zeitwerk has no problems with this
• view_component_storybook adds Pathname app/components to autoload
• Pathname app/components is not the same as string app/components, and so in the setup_autoloaders method of ActiveSupport, app/components is not recognized as eager_loaded, and is specifically removed from eager_loading
• The app/components that rails added to eager load is no longer set to eager load
• No app/components get loaded past this point ¯_(ツ)_/¯

The workaround is simple: just use to_s on Rails.root.join("app/components"). However, since this seems to be unexpected behavior, I figured I'd raise the issue here.

Ref: ViewComponent/view_component#869

[jonspalmer]

I made a small tweak to the way stories_paths are added #143 I suspect this fixes the problem you describe with both a to_s and being more careful about adding to autoload. The change is a little hard to unit test but looks reasonable on inspection. Maybe you can checkout the branch in PR and verify that it solves your problem and we can merge it