Weave Code
Dictionary Bundle Laravel Package
knplabs/dictionary-bundle
KnpDictionaryBundle lets you group tagged services into named dictionaries and fetch them by key at runtime, instead of wiring each dependency individually. Great for plugin-style architectures, handler registries, and any collection of services you want to look up dynamically without boilerplate co...
Are you often tired to repeat static choices like gender or civility in your apps ?
Frequently asked questions about Dictionary Bundle
- Can I use knplabs/dictionary-bundle in a Laravel application?
- Not as an installed dependency. It is a Symfony bundle built on compiler passes, DI tags, Twig extensions, Form types, Validator constraints and a web-profiler collector, and none of that surface has a Laravel consumer, so roughly 60 to 70 percent of the integration layer is inert here. The portable part is the core Dictionary namespace: callable-backed, iterator-backed and static dictionaries plus a Collection registry and a Factory alias. In practice you would copy that in-memory value-object layer into a Laravel service provider and a config file rather than requiring the package.
- How do I install and register the dictionary bundle in a Symfony app?
- You install it with Composer using knplabs/dictionary-bundle and then enable KnpDictionaryBundle in your bundle registration file so its DI extension is loaded. After that, dictionaries are declared under the bundle's configuration key rather than in code. Note that the repository keeps a legacy nested PSR-4 layout under src/Knp/DictionaryBundle instead of a flat src directory, which matters if you plan to fork or extract classes because namespaces must be re-mapped.
- How do I define a dictionary in YAML, XML or PHP configuration?
- You declare named collections of key-value pairs in the bundle configuration in any of the three supported formats, and each named collection becomes an addressable dictionary. The values are read-only, so the bundle is a good fit for enums, status labels and shared lookup data that would otherwise be scattered across constants. There is no database or extra storage involved, so anything that needs runtime editing belongs elsewhere.
- How do I fetch a dictionary value at runtime in Symfony?
- You either autowire the dedicated dictionary service for a given name or pull it from the central registry, then look values up by key. Because resolution happens through the DI container, the lookup is a plain in-memory array access with no I/O cost. For simple enum-style data in Laravel, a native backed enum plus a config file gives you the same read-only semantics with less machinery.
- What is named dictionary autowiring in version 3.6.0 and does Laravel have an equivalent?
- Version 3.6.0 added named dictionary autowiring delivered entirely through Symfony's DI autowiring and alias machinery, resolving named service aliases by parameter type plus name. That is the clearest illustration of the framework ceiling here, because Laravel has no named-autowiring analog. Laravel's contextual binding, using when, needs and give, solves a different problem shape and is not a sensible foundation for a registry feature. If you want this capability in Laravel you are copying the bundle's wiring patterns, which is exactly the outcome to avoid.
- Which Laravel and PHP versions does this package support?
- There is no Laravel support at all, in any version, because the package is Symfony-specific. On the PHP side the project is current: release 3.6.0 added PHP 8.4 and 8.5 support and opened CI for Symfony 7.1. If your decision record needs a Laravel compatibility statement, the honest answer is none rather than a version matrix.
- What are the Laravel alternatives for enums, status labels and lookup data?
- For the common case, PHP 8.1+ backed enums with a label method cover status labels and fixed option sets without any package. Laravel's config repository handles shared lookup arrays, Rule::in covers validation against allowed values, and tagged container bindings or a small custom registry service cover dynamic service lookup. A hand-written service provider plus a config file reproduces the bundle's portable core in a few hundred lines. That reimplementation path is generally cheaper than extracting the upstream code.
- Can I write a custom dictionary implementation?
- Yes. Release 3.6.0 published documentation for implementing custom dictionaries, which promotes the Dictionary interface to a supported extension point rather than something you had to infer from source. That is genuinely useful for an extraction because the seam you need is now a documented contract. It does not change the fact that the surrounding adapters are Symfony-only.
- How is the bundle tested, and does that complicate extracting the core?
- The suite is PHPSpec-based and depends on a local Prophecy extension plus a custom shouldBeOneOf matcher living under spec/PHPSpec. Combined with the nested PSR-4 source layout, that means a fork must re-point namespaces and the spec tree before the tests run cleanly. The friction is structural rather than documentary, so budget for it if you intend to vendor the Dictionary classes.
- Is the project actively maintained and safe for production use?
- The maintenance signals are healthy: CI now covers Symfony 7.1 and PHP 8.4 and 8.5, and the dev toolchain was carried through major upgrades to PHPStan 2.1.27, Rector 2.1.7, php-cs-fixer 3.58+ and Prophecy 1.19, so the legacy layout should be read as an extraction cost rather than a sign of slow response. Runtime risk is low because everything is read-only and in-memory with no database, though the container-compile-time ordering constraints around dictionaries are an area to watch when composing multiple dictionaries. The open question is downstream validation: the 3.6.0 notes show no evidence of production consumers, so reconcile the dependent count against Packagist before citing it in a decision record.
Weaver
How can I help you explore Laravel packages today?