Provides setter injection traits in order to ease dependency injection of Drupal services.
GPL-2.0 License
(c) 2017-2023 drunomics GmbH
Provides setter injection traits in order to ease dependency injection of services.
Major version numbers match Drupal core compatibility, e.g.
2.x -> Drupal 8.2.x
3.x -> Drupal 8.3.x
4.x -> Drupal 8.4.x
5.x -> Drupal 8.5.x
6.x -> Drupal 8.6.x
7.x -> Drupal 8.7.x
8.x -> Drupal 8.8.x
9.x -> Drupal 8.9.x
9.1.x -> Drupal 9.1.x
9.2.x -> Drupal 9.2.x
9.3.x -> Drupal 9.3.x
9.4.x -> Drupal 9.4.x
10.x -> Drupal 10.x
After changes in a branch we need to create a new appropriate release.
8.x -> 8.8.0, 8.8.1, ...
9.x -> 8.9.0, 8.9.1, ...
9.1.x -> 9.1.0, 9.1.1, ...
9.2.x -> 9.2.0, 9.2.1, ...
9.3.x -> 9.3.0, 9.3.1, ...
9.4.x -> 9.4.0, 9.4.1, ...
10.x -> 10.0.0, 10.0.1, ...
This covers traits for services that are missing from core or contrib modules.
Install the package via composer require drunomics/service-utils
Just "use" the trait for the service you want to use. The trait provides a
suiting getter; e.g., getEntityTypeManager()
.
composer install
./vendor/bin/phpunit # or use the shortcut
composer test
To check the coding style for the project's custom code, run PHP code sniffer:
composer cs
To automatically fix the coding style errors (as far as possible), run the PHP code beautifier:
composer cbf
Why are the traits not added to the upstream source (core or contrib modules) instead?
This would be the best option, but results in a worse developer experience (DX) while patches are not committed. The goal of this package is to make dependency injection almost as quick as calling out to \Drupal::container(), thus adding in a patch every time a dependency is needed is taking too long and so results in a worse DX.
The suggested workflow is to quickly add missing traits to this package, so they are immediately available for everyone's use. On a regular basis, patches for traits should be filed against upstream projects in order to improve them and deprecate this package in the long term. Once those patches landed in new upstream releases, the service-utils usages could be replaced and the package can be safely dropped from a project.
Why is this no project on drupal.org?
Because drupal.org has no project type for composer packages and using Github with Travis for tests is convenient.