Tools Bundle Laravel Package

Getting Started

This is a Symfony bundle with minimal public documentation and very low adoption (2 stars, 0 dependents), so treat the source as the spec. Installation is the standard Symfony bundle flow:

composer require wandi/tools-bundle

Register it in config/bundles.php:

return [
    // ...
    Wandi\ToolsBundle\WandiToolsBundle::class => ['all' => true],
];

Then, before writing any code, read these three things in order:

1. composer.json — reveals the supported Symfony/PHP version range and any transitive dependencies you are about to inherit.
2. The bundle class (*Bundle.php) and DependencyInjection/ — shows whether configuration is exposed and how services are wired (autowiring vs. explicit XML/YAML).
3. src/ — enumerate every class. With a bundle this small, the entire surface area is readable in minutes, and this is the only reliable documentation.

A sensible first use case is to run bin/console debug:container --show-private | grep -i wandi after registration. That tells you exactly which services the bundle contributes to your container, which is faster than guessing from filenames. Pick one self-contained utility (a helper, a Twig extension, a form type) and exercise it in a throwaway controller or a single unit test before wiring it into production code.

If the bundle exposes no services at all and only ships static helpers, you are effectively installing a small library with a Symfony integration shim — in that case, importing the classes directly is fine and you can skip bundle registration entirely.

Implementation Patterns

Isolate the dependency behind your own service. Because the package is unmaintained-looking and unversioned in practice, do not scatter use Wandi\ToolsBundle\... imports across your application. Wrap the functionality you actually use in an application-level service:

final class MyApp\Util\Slugger
{
    public function __construct(private readonly \Wandi\ToolsBundle\Util\Slugger $inner) {}

    public function slug(string $value): string
    {
        return $this->inner->slug($value);
    }
}

If the vendor package dies or you need to fork it, you change one class.

Prefer direct instantiation for stateless helpers. Utility bundles rarely benefit from container indirection. If a class has no dependencies, new Foo() in your service is simpler, faster, and easier to test than pulling it from the container and mocking it.

Use the bundle's services as decorators, not as your API. If the bundle ships a Doctrine listener, a normalizer, or a Twig extension, leave it in place but build your own thin layer on top when your behaviour diverges. Decorating a Symfony service via services.yaml is trivial:

services:
    App\Decorator\WandiThingDecorator:
        decorates: wandi_tools.some_service
        arguments: ['@.inner']

Test at the boundary. Whatever you consume from the bundle, assert only on its public contract in your own test suite. Since the package has no dependents, there is no community guarantee that signatures are stable across patch releases — your tests become the compatibility harness.

Pin the version explicitly. Use an exact constraint ("wandi/tools-bundle": "1.2.3") or, safer, commit a composer.lock and be disciplined about not running composer update blindly. With 0 dependents, a broken release is unlikely to be caught by anyone else before it hits you.

Gotchas and Tips

• Treat the README as advisory. Verify every documented method signature against src/. With this level of adoption, docs and code drift.
• Check Symfony compatibility before upgrading. The bundle class and DI extension syntax changed several times across Symfony versions (TreeBuilder API, service autowiring defaults, Extension::load signatures). If you upgrade the framework, smoke-test this bundle first — it will not be flagged by any tooling.
• Watch for implicit global state. Utility bundles frequently register Twig extensions, Doctrine subscribers, or event listeners via services.yaml tags. These activate automatically and can surprise you in tests. Inspect Resources/config/ for tags and disable them per-environment if you do not want them globally.
• Configuration defaults may not exist. If DependencyInjection/Configuration.php is absent, the bundle has no config tree — wandi_tools: in config/packages/*.yaml will fail with an unknown-key error. Only add config if you have confirmed the extension defines a node.
• Debugging: for any service the bundle provides, bin/console debug:container <service_id> shows the class, tags, and public/private status. For tagged services (listeners, extensions), bin/console debug:event-dispatcher and bin/console debug:twig will reveal whether the bundle's hooks actually fired.
• Extension points are minimal. With no configuration tree and no documented interfaces, the realistic extension mechanism is decorating services or extending classes where they are not final. Check for final before planning a subclass.
• Fork as a fallback. Because the package has essentially no downstream users, an abandoned release is a real risk. Mirror the relevant classes into your own codebase (respecting the license in composer.json / LICENSE) rather than relying on it remaining installable — this also eliminates a supply-chain surface you are not otherwise auditing.
• Security review. A 0-dependent, 2-star package receives no security scrutiny. If it touches file I/O, unserialization, or shell execution, read those methods line-by-line before adoption.