ViewComponent::Base itself will always use the defaults. Any classes inheriting from ViewComponent::Base will cascade config down using InheritableOptions, only specifying any overrides.
Generate options being on their own "layer of config is currently unresolved - it might be that config needs to be a new object inheriting from InheritableOptions that has method accessors for everything in that namespace.

This was initially written to support extracting the incoming strict_helpers_enabled? option, but applies to everything.

…config as necessary

No settings actually use it, but this would be the way to introduce it once we come to need it.

* Fix duplicate template error bug

This change fixes the bug reported where a component will report that it
has both a template and a `call` method defined despite only having an
HTML template.

I was able to reproduce this bug by pulling in Avo (like reported in the
initial bug report) and running `vegeta` (to trigger parallel requests
since I had a hunch this was a race condition):

```
echo "GET http://localhost:3000/avo/resources/cars/1" | vegeta attack -duration=2s
```

This reliably reproduced the error:

```
ActionView::Template::Error (Template file and inline render method found for Avo::CoverPhotoComponent. There can only be a template file or inline render method per component.
Template file and inline render method found for variant '' in Avo::CoverPhotoComponent. There can only be a template file or inline render method per variant.
Templates:
```

I added _a lot_ of debug logs to understand the race condition that I
thought was occurring, and realized that multiple threads are calling
`gather_templates` _and_ mutating the `@templates` array at the
same.When looking at the old compiler code and realized that this likely
isn't new behavior. This led the investigation towards how we collect
and surface errors or otherwise might modify templates. It turns out
there's a difference in the new and old compiler code after the
refactor:

```ruby
\# old
def template_errors
  @__vc_template_errors ||=

\# new
def gather_template_errors(raise_errors)
  errors = []
```

_We're not memoizing the errors like we used to_. This is more correct
behavior, but explains how a race condition would make this error case
much more difficult to occur in older versions of the compiler.

This change brings us back to the old behavior by memoizing the errors
we collect in `gather_template_errors` but the `@templates` ivar is
still being mutated. I don't want to change _too much_ in this PR, but a
subsequent change might be wrapping the entire `compile` method in the
`redefinition_lock` (and renaming it to `compile_lock`) to avoid similar
issues in the future.

I did not include a test because it's dfficult to reproduce this race
condition reliably in the test environment.

I believe this _should_ close out ViewComponent#2114

* Fix tests, raise errors for compiled components with errors

* There isn't always a default template when there are errors.

* Make standard happy

ugh

* Remove debug code

* Fail compilation when errors present

* Revert default template change

* Add informative comment

* Add changelog

---------

Co-authored-by: Joel Hawksley <[email protected]>