I’ve recently created i18n package that is PHP-generic message translation/formatting package. While planning it dependencies were analyzed and some decisions were made:
- Suggested packagist dependencies aren’t particularly good. They’re hiding a problem in package dependencies.
- A generic package, that framework will likely depend on, should be as stable as possible. That means containing only interfaces or, in a less ideal but practical world, interfaces and part of the implementation that is unlikely to change.
- Specific backends/drivers should be in their own packages as:
Such structure makes it possible to depend on
i18nbut not to require intl extension or
dbpackage except in the application itself that is by definition the most unstable package. Another profit is that these drivers could be maintained/released separately.
I am going to follow the same approach for RBAC, mutex and other packages where there are multiple ways of storing data.