Tools Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony bundle, not a Laravel package. It ships with a Symfony Bundle class (typically extending Symfony\Component\HttpKernel\Bundle\Bundle) and expects to be registered in config/bundles.php inside a Symfony kernel. There is no ServiceProvider, no Facade, no Laravel auto-discovery, and no provides()/aliases contract. A composer require in a Laravel app will install the code, but nothing will be wired up for you.

First things to check, in this order:

1. composer.json on the repo — confirm the require block. Look for symfony/framework-bundle and the Symfony version constraints (e.g. ^5.4|^6.0 or similar). This tells you how far behind it is and whether it will even resolve on modern PHP.
2. src/ — "Tools bundle" is a generic label with no README-level explanation. Open the directory and enumerate what's actually there: services? console commands? Twig extensions? annotations/attributes? validators? helper traits? Most small author bundles are one of these.
3. The last commit date and tag history — 0 stars / 0 dependents means you are the first real consumer. That is a strong signal to read the code, not the description.

Your realistic first use case as a Laravel developer is not "install this bundle." It is "find the 1–2 utility classes in it that solve a problem, copy them into app/Support/, and strip the Symfony-specific dependencies." The bundle wrapper itself is dead weight outside Symfony.

Implementation Patterns

Given the Symfony-vs-Laravel mismatch, there are three honest integration patterns, roughly in order of how often you should pick them:

Pattern A — Vendor the useful class (recommended). Identify the class you actually want (a string helper, a collection utility, a formatter, etc.), copy it into your app, replace Symfony dependencies with Laravel equivalents (Illuminate\Support\Str, Illuminate\Support\Collection, the container). Add a test. This is almost always the right move for a single-purpose tool bundle with no ecosystem around it.

Pattern B — Bridge via a custom ServiceProvider. If a class is genuinely useful and self-contained but you don't want to fork it:

// app/Providers/ToolsBundleServiceProvider.php
public function register(): void
{
    $this->app->singleton(\Neirda24\ToolsBundle\SomeService::class, function ($app) {
        return new \Neirda24\ToolsBundle\SomeService(
            // explicitly construct its deps; do NOT expect the bundle
            // to autowire anything for you outside Symfony's kernel
        );
    });
}

Only do this if the class has no hard dependency on Symfony services (EventDispatcherInterface, RequestStack, config tree builders, etc.). If it does, fall back to Pattern A.

Pattern C — Actually run it inside Symfony (only if your project is Symfony). Register in config/bundles.php, add a config/packages/tools.yaml for any configuration tree the bundle exposes, and inject services by interface. This is the intended path and will just work — but it's irrelevant to a Laravel codebase.

For testing integration regardless of pattern: wrap whatever you use behind a small interface (e.g. App\Contracts\Toolbox) so you can swap it for a Laravel-native library later without touching call sites.

Gotchas and Tips

• Zero adopters is the headline. 0 stars and 0 dependents means no community bug reports, no StackOverflow answers, no one has hit the edge cases before you. Treat it as "read-before-use code," not a dependency. At minimum, skim every file in src/ before it touches production.
• Silent install, silent failure. Without Laravel package discovery, a successful composer require will do nothing useful. If you assume it "just works" you'll spend an hour debugging why your facade doesn't exist. There is no facade. There is no alias.
• Version resolution is the first real blocker. Small Symfony bundles get abandoned faster than the Symfony versions they target. Check the require block against your PHP version (8.3/8.4 break a lot of older bundles) and against symfony/* constraints. composer why-not neirda24/tools-bundle is your friend if the install fails.
• Bundle class vs. services. Even in Symfony, remember that registering the bundle does not mean the services are public. If you need one, use constructor injection or explicitly alias it into a test container.
• Debugging on the Laravel side. When a bridged service throws, it usually throws from deep inside a Symfony component (OptionsResolver, Config definition, ParameterBag) that Laravel doesn't autoload the way you expect. Use composer show neirda24/tools-bundle to confirm the version, and dd(get_class_methods($service)) to see what you're actually holding.
• Config quirks. If the bundle defines a Configuration tree, any custom tools.yaml you write in a Laravel project is ignored — Laravel doesn't parse YAML bundle config. Pass config as constructor arguments or an array in your ServiceProvider instead.
• Extension points are thin. Tool bundles of this size usually expose extension by inheritance of their helper classes rather than by events or an SPI. That means upgrading to a new tag can break your subclasses. Pin the version in composer.json (e.g. "neirda24/tools-bundle": "1.2.*") if you choose Pattern B.
• The real recommendation: for a package this obscure, the cost of the dependency (version drift, no upstream fixes, Symfony coupling) usually exceeds the cost of copying the 200–400 lines of code you actually need. Fork it or vendor it; don't depend on it.