You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
@acoulton regarding the option to use packagist, annoyingly some behat extensions do not declare themselves with that type. For example FriendsOfBehat/SymfonyExtension declares its type as symfony-bundle 😞
type is meant primarily to refer to packages needing a specific installation method (the symfony/flex plugin relies on the symfony-bundle type 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.
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).
The text was updated successfully, but these errors were encountered: