Could container raise error on finalization when component is not resolvable?

[cllns]

Describe the bug/feature

I ran into an issue where I had defined a constant with an acronym in the name and registered in with dry-system. I just needed to define the acronym in the inflector, but I wonder if we should even successfully finalize! when a (non-lazy loaded) component is unresolvable. Instead, we could raise an error with a name like ComponentNotResolvableError.

Lazy-loaded components won't have their constants defined at finalization, so this would only be for non-lazy loaded components.

To Reproduce

git clone git@github.com:cllns/dry-system-unresolvable-component-example.git cllns-dry-system-unresolvable-component-example
cd cllns-dry-system-unresolvable-component-example/
bundle 
bundle exec ruby lib/container.rb

You'll get a NameError because the class is called HTML which isn't recognized by the inflector, (though the API class is, so that works fine.)

Expected behavior

Running .finalize! on a container would check to see if constants that correspond to each key that's registered are defined. It shouldn't actually resolve the components, but it should check to see if the components are resolveable (preresolve?)

I guess the question is: does dry-system need to support constants defined after a container has been finalize!'d.
If it does, then we can wrap NameError via implement #147 and that will be helpful enough for users. UPDATE: This is complete

I can take a swing at implementing this, if you think it's a worthwhile feature.

[timriley]

@cllns I think you're onto something here. It actually relates to some of the work I've been doing lately too, with #197 adding a hook for Zeitwerk to do its own eager-loading when we finalize the container in the production mode. So yes, I do wonder if we need to build some kind of more general-purpose "eager load" step into the finalization process. I think it's definitely in keeping with the spirit of finalization.

So I'm open to exploring this idea. In the meantime, however, I think #147 is still great to have since we'll want that for the cases when we're not eager loading, such as when the containers remain non-finalized.

[solnic]

I think it's worth getting this into 1.0.0. Getting confusing exceptions can be frustrating for the users, especially people who are trying out dry-system/hanami2 for the first time. Using acronyms in names is common, so this may bite many people.

[timriley]

@solnic FYI, we've already done the work to provide clear error messages via @cllns' work in #217.

This issue is about whether we should try and access the constant for every auto-registered component as part of the finalization process, instead of waiting for those components to be later resolved.

This would slow down finalization somewhat, but would have the benefit of bringing error messages forward in time.

[solnic]

@timriley yeah I know thanks! Verifying constants is a good thing to do, mismatches will happen. We could maybe either have it done by default or have a special verbose/verification mode that you can enable to verify your setup.

[timriley]

I was thinking we could just do this at finalization, but allow opt-out, eg.

Container.finalize(eager_load: false) # defaults to true

What do you think?

[solnic]

Makes sense!