Removing shared-component installation code smells and maintainability issues

What would have to change in Phoenix LiveView to allow a shared component ecosystem to flourish?

I have seen some lamentations about the need for a solid, go-to component library, like MUI for React. But I am not sure that’s the problem. To me it seems like the Phoenix framework may need some light tweaking so that a robust shared component (or component library) can be shared without creating maintainability issues.

For example, Serge Aleynikov riffs off of a tutorial from Berenice Medel on the Fly site to make this multiselect widget. But to install it, you can’t just run mix deps.get. You’ve also got to run a special installer that will modify assets/tailwind.config.js, assets/js/hooks/multi-select-hook.js, assets/js/hooks/index.js. It’s really nice the author adds that installer to the package, but it feels like he shouldn’t have to – and like we’re going to run into problems down the road due to the weak encapsulation. E.g., naming conflicts with hook; and/or poorly-executed code surgery on any one of these files, resulting in a broken project.

Component libraries like Petal Components also resort to installation processes that smell like future maintainability PITAs. You have to edit tailwind.config.js; add the component library’s css to app.css; add a “use” statement to MyApp_web.ex; and then deal with name conflicts for a number of the core_components.ex widgets.

So back to the question! Do folks have a sense of what (if any) framework improvements are needed to make it possible to share robust components or component libraries without code-smelly installation and name conflict issues?