Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/fmasa/auto-di
:star: :wrench: Automatic registration and configuration of services for Nette DI
https://github.com/fmasa/auto-di
Last synced: 3 months ago
JSON representation
:star: :wrench: Automatic registration and configuration of services for Nette DI
- Host: GitHub
- URL: https://github.com/fmasa/auto-di
- Owner: fmasa
- License: mit
- Created: 2017-09-23T10:48:57.000Z (over 7 years ago)
- Default Branch: 2.x
- Last Pushed: 2020-02-23T16:06:45.000Z (almost 5 years ago)
- Last Synced: 2024-10-17T22:46:09.246Z (3 months ago)
- Language: PHP
- Homepage:
- Size: 56.6 KB
- Stars: 15
- Watchers: 3
- Forks: 3
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Service auto registration and configuration for Nette DI
[](https://travis-ci.org/fmasa/auto-di)
[](https://coveralls.io/github/fmasa/auto-di?branch=2.x)
`fmasa\autoDI` is package intended to make registration and configuration
of services easier.
## Future of extension
In Nette 3.0, [SearchExtension](https://doc.nette.org/en/3.0/di-builtin-extensions#toc-searchextension) was introduced.
It builds on the same concept as this extension (in which I stole the concept from Symfony DependencyInjection).
Unfortunately there are still a few problems that need to be fixed in order to fully replace `fmasa/auto-di` (i.e. [nette/di#215](https://github.com/nette/di/issues/215)), but it's on the other hand part of Nette DI core and supports several features, that `fmasa/auto-di` doesn't (yet).
These are ways to register services implementing specific interface or extending specific class.
So long-term goal is to deprecate this extension in favor of SearchExtension, when (and if) SearchExtension reaches feature parity.
Until then I plan to maintain and improve this package since I use it myself in many projects.
## Installation
The best way to install fmasa/auto-di is using [Composer](https://getcomposer.org/):
$ composer require fmasa/auto-di
To enable auto registration register extension in your `config.neon`:
```yaml
extensions:
autoDI: Fmasa\AutoDI\DI\AutoDIExtension
```
## Pattern based definition
`autoDI` registers services defined by regex:
```yaml
autoDI:
services:
- class: App\Model\**\*Repository
```
This registers every class under namespace `App\Model` which name ends with `Repository`:
- App\Model\Eshop\UserRepository
- App\Model\CMS\Comments\CommentsRepository
There are several simple operators that can be used in patterns:
- `*` matches class name, one namespace level or part of it (without \\)
- `**` matches any part of namespace or classname (including \\)
- `{Eshop,CMS}` options list, any item of list matches this pattern
Apart from these, any PCRE regular expression can be used.
## Classes and generated factories
Package supports both classes and [generated factories](https://doc.nette.org/en/2.4/di-usage#toc-component-factory).
Classes are matched agains `class` field, factories againts `implement` field,
which corresponds to way Nette use these fields.
When using `class` field, all matching interfaces are skipped and vice versa.
```yaml
autoDI:
services:
# Repositories
- class: App\Model\**\*Repository
# Component factories
- implement: App\Components\very**\I*Factory
```
## Tags, autowiring, ...
Every option supported in DI (tags, inject, autowiring, ...) is supported with same syntax
as normal service registration
```yaml
autoDI:
services:
# Repositories
- class: App\Model\Subscribers\**
tags: [eventBus.subscriber]
```
The snippet above registers all classes in `App\Model\Subscribers` namespace
with `eventBus.subscriber` tag.
## Exclude services
Sometimes we wan't to exlude certain services from registration. For that we can use `exclude` field,
that accepts pattern or list of patterns:
```yaml
autoDI:
services:
- class: App\Model\**
exclude: App\Model\{Entities,DTO}**
```
which is same as
```yaml
autoDI:
services:
- class: App\Model\**
exclude:
- App\Model\Entities**
- App\Model\DTO**
```
## Already registered services
When extension founds service, that is already registered
(by `services` section, different extension or previous `autoDI` definition), **it's skipped**.
This allows manual registration of specific services that need specific configuration.
## Defaults section
To specify base configuration for all services registered via `autoDI`, `defaults` section
can be used:
```yaml
autoDI:
defaults:
tags: [ my.auto.service ]
services:
# these services will have tag my.auto.service
- class: App\Model\Repositories\**
# these services will have only tag eventBus.subscriber
- class: app\Model\Subscribers\**
tags: [ eventBus.subscriber ]
```
## Configuring directories
By default extension searches for services in `%appDir%`, but other directories can be specified:
```yaml
autoDI:
directories:
- %appDir%
- %appDir%/../vendor
```
## Register services on configuration
Compiler extensions such as AutoDIExtension manipulates the DI container
in two phases (configuration loading and before compilation).
By default this extension registers all services before compilation.
This may not be optimal if you wan't to use this extension with other extensions
such as decorator.
You can enforce registration in configuration phase
by setting `registerOnConfiguration` option to true.
When no service is registered for configuration entry, either because no class/interface
matches the pattern or all matched services were already registered in container, exception
is thrown. This check can be disabled by setting `errorOnNotMatchedDefinitions` option to false.