askvortsov needing to install 20-30 extensions can also be crowded, confusing, and result in extension clashes
I've long (though not loudly) advocated for savvy community members to create "extension bundles" or extensions that are nothing more than a composer.json file that calls the installation of other extensions through the Composer
require command. You can see this in action in the BBBBCodes Extension. Essentially, just a curated pack of extensions that someone has selected and tested to ensure they work together well. It's a middle-man step that some might see as extraneous, it might slow down upgrades for some extensions as bundle maintainers would have to test before updating, but it would give some users a peace of mind and convenience that seems to be a growing need in the Flarum ecosystem.
This would alleviate points 1, 2 and 4. I understand the joy of having a one step installation, but this approach ignores the fundamental structure of Flarum. It's built to be a framework that can be extended. Default bundling of extensions means, for the Flarum team, that they take on the development and maintenance of those extensions in an official capacity. That's obviously not ideal when our core software is still in beta, and we're pushing hard to reach a stable version for the API (which will, in turn, give greater stability to extension developers). This is why development teams like Flagrow, Reflar and now Friends of Flarum have risen up and tackle extensions that are useful and considered necessary, but are too much for our core development team to take on officially.
askvortsov The lack of documentation of extenders, actions/listeners, REST API, Authentication, etc is a barrier to entry for extension developers. I believe this is being worked on, but wanted to mention it regardless
This is an excellent point, and one that we struggle with as a team. We had some documentation writers, once upon a time, but they didn't survive in that same capacity. Flarum could definitely use new ones, folks who are interested in writing technical documents for others to follow, and who have the capacity to learn to understand code. If that's you, feel free to reach out to me on Discord.
askvortsov Some extensions depend on / are incompatible with other extensions. Maybe we could add a check to the extension activation system that wouldn't let you activate an extension if it's incompatible with a currently installed extension, or depends on an extension that isn't installed. Would also require de-activating a dependency before deactivating the dependent extension. Incompatibilities and dependencies could be specified by extension authors
This is actually possible to do with composer.json, it simply requires extension developers to be aware of incompatibilities and assert the protections their extension needs. If any developers are reading this and need to know how to do this, check out the Composer