Fix require.context bug

[Paul-Bob]

Description

This PR refactors the Stimulus controller registration process to be dynamic and automated, eliminating the need for manual application.register() calls.

The primary motivation is to simplify controller management, reduce boilerplate, and provide a robust solution that avoids webpack-specific features like require.context, ensuring broader compatibility.

The changes introduce:

• A CONTROLLERS array that lists controller names (snake_case) and their corresponding classes.
• A SPECIAL_CASES object for custom registration names (e.g., nested_form to avo-nested-form).
• A dynamic loop that iterates through the CONTROLLERS array, converting names to kebab-case (unless a special case applies) and registering them with the Stimulus application.

This approach makes adding new controllers significantly easier (just import and add to the array) and centralizes naming conventions.

Fixes # (issue)

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works

Screenshots & recording

Manual review steps

1. Start the application.
2. Navigate to various Avo resources and pages that use Stimulus controllers (e.g., index, show, edit views, filters, actions).
3. Verify that all interactive elements (filters, search, pagination, modals, fields like Trix, etc.) continue to function correctly, indicating that their respective Stimulus controllers are properly registered and active.
4. Check the browser console for any JavaScript errors related to Stimulus controller registration or missing controllers.

Manual reviewer: please leave a comment with output from the test if that's the case.

---

_{Learn more about Cursor Agents}

[adrianthedev]

Is there a reason to not make this like the others and eliminate the special cases?

[Paul-Bob]

Yes, since we're extending NestedForm from 'stimulus-rails-nested-form', and the common way to import this controller is as nested-form, it was causing conflicts with parent apps that also use nested-form.

[Paul-Bob]

related PR #3864

[adrianthedev]

ok. but what stops us to name it like that?

data-controller="avo-nested-form"

[adrianthedev]

or, change the name that we can change

[Paul-Bob]

I'm sorry could you rephrase? I didn't get your question

---

I will assume that by "like that" you mean nested-form.

There are apps using avo that also import stimulus-rails-nested-form and register it under the same name: nested-form. This results in two controllers being registered with the same identifier.

In the app where I encountered and resolved this issue (via the PR linked above), the conflict manifested as duplicate behavior: clicking the "add" button, which was using data-controller="nested-form" would create two new entries per click, one from our (avo) controller and one from the parent app's controller.

[adrianthedev]

And we then can infer the names.
So in teh end we'd end up with somethign like this

import ActionController from ...
import ...
import ...

registerControllers(application, [Actioncontroller, ..., ...])

it would be easier for us to implement this as well
#2030

[Paul-Bob]

Closing this PR since this was made by cursor during some development experimentation that I was doing (can't remeber asking or allowing it but probably i did :D)