Repository navigation
Consider if / how to promote third-party extensions #150
Description
Currently the "Extensions" nav link in the docs just goes to a github search for "behat extension" in the name or description
A lot of extensions have a composer type of behat-extension so a packagist search for that type might give more useful results (for a start, it would only show things people have actually published rather than forks / experiments / etc).
I wouldn't object to having our own page of extensions in the docs and allowing people to submit their own to be listed. Someone did the very beginning of that years ago but it seems it didn't get anywhere. We'd need to make clear it was essentially a wiki, and the extensions themselves weren't officially reviewed or approved by us. Having our own page would mean we could e.g. group things by the type of functionality they offer. It would also make it easier for users to see when new extensions are added (from the change history on the docs).
Activity
carlos-granados commentedon Nov 6, 2024
@acoulton regarding the option to use packagist, annoyingly some behat extensions do not declare themselves with that type. For example
FriendsOfBehat/SymfonyExtensiondeclares its type assymfony-bundle😞stof commentedon Nov 6, 2024
typeis meant primarily to refer to packages needing a specific installation method (thesymfony/flexplugin relies on thesymfony-bundletype to automatically register bundles in the kernel during installation).For the case of identifying Behat extensions, using a keyword would be more suitable (IIRC, packagist calls them "tags" in its search filters). and packages can have multiple keywords applied on them, making this less restrictive that forcing to use a specific type.