Toolkitbundle Laravel Package

Getting Started

First, confirm what you actually have. Despite the "Laravel-friendly integration" line in the description, kmj/toolkitbundle is named and structured as a Symfony bundle (Demoboy/ToolkitBundle, *Bundle class convention). With 0 stars, 0 dependents, and a score of 0, treat it as unvetted source until you've read it. Do not add it to composer.json on anything in a request path before you've done a spike.

Minimal steps:

1. Inspect the metadata before installing.

   composer show kmj/toolkitbundle
   

   Look at type (expect symfony-bundle), the PHP and framework constraint ranges, and whether it pulls symfony/framework-bundle or illuminate/*. That single field decides your integration path.

2. Read these files first, in order:

   • README.md — install and config instructions (may be absent; if so, that's your answer)
   • composer.json — framework constraints and autoload map
   • src/*Bundle.php — the bundle class and its getContainerExtension()
   • src/DependencyInjection/Configuration.php — the config tree, which is the real public API
   • src/DependencyInjection/*Extension.php — service IDs that get registered
   • Resources/config/services.* — definitions you may need to override

3. Pick your path based on that read.

   • Symfony app: register in config/bundles.php, add a config block using the extension alias, then bin/console cache:clear.
   • Laravel app: the bundle will not auto-discover. There is no bundles.php, no compiler pass, no debug:container. Your only realistic options are (a) call the framework-agnostic utility classes directly via Composer autoload, or (b) copy the handful of helpers you want into your own package with a real ServiceProvider. Do not try to register the Symfony bundle class inside Laravel.

4. First use case — the smallest isolated service. Resolve one helper to prove wiring works before adopting anything broader:

   bin/console debug:container --show-private | grep -i kmj
   

   Then use it once in a test or a tinker session.

If there is no README and no tagged release, stop and evaluate a fork-and-vendor approach rather than depending on upstream.

Implementation Patterns

Symfony-native usage (the intended path). Register the bundle, then configure through the extension alias instead of touching vendor files:

// config/bundles.php
Kmj\ToolkitBundle\KmjToolkitBundle::class => ['all' => true],

# config/packages/kmj_toolkit.yaml
kmj_toolkit:
  # copy the keys straight from DependencyInjection/Configuration.php

Prefer constructor injection by service ID over pulling from the container — that's how you keep the option to swap or remove the package cheap:

final class ReportBuilder
{
    public function __construct(private MyFormatter $formatter) {}
}

Laravel-side usage (the realistic path). Since the framework-agnostic core is PSR-friendly, the sane pattern is to depend on the classes directly, not the bundle:

namespace App\Support;

use Kmj\ToolkitBundle\Util\SomeFormatter;

final class FormatterAdapter
{
    public function __construct(private SomeFormatter $inner) {}

    public function format(array $row): string
    {
        return $this->inner->format($row);
    }
}

Bind it in a service provider and inject FormatterAdapter everywhere. Your application code never mentions the package, so removal is a one-file delete:

// app/Providers/AppServiceProvider.php
$this->app->bind(FormatterAdapter::class, function () {
    return new FormatterAdapter(new SomeFormatter(config('toolkit.options', [])));
});

Day-to-day workflow. This is a borrow the ideas package, not a build on package:

• Isolate a spike on a throwaway branch, exercise the helpers against your real data shape, and record which ones actually earn a place.
• For anything that survives, reimplement it in-house (or copy with attribution) under your own test suite. Given zero adoption signals, that's lower total cost than depending on an orphan.
• If you do vendor it, pin the version, wrap it behind an internal interface as above, and add contract tests covering exactly the behavior you rely on. Keep it off critical paths — admin/ops tooling, one-off import/export helpers, prototype scaffolding — never auth, payments, or anything touching PII.
• Skip it entirely where it overlaps Illuminate\Support, Str, Arr, Collection, Http, or Pipeline — which, for a generic "toolkit" of string/array/formatting helpers, is most of it.

Gotchas and Tips

• The naming is the first gotcha. "Bundle" means Symfony. If your composer.json require shows symfony/framework-bundle, it is not a Laravel package and won't drop into Laravel's container, config publishing, or facade conventions without an adapter — that's a port, not an install.
• The config tree is the API. There's no facade or documented surface; read DependencyInjection/Configuration.php and Extension.php to learn the actual service IDs and config keys. Override services in your app config, never in vendor/.
• Constraint mismatch is a non-starter. If the PHP or framework range won't accept your stack, don't hack around it — an abandoned constraint range will eventually pin your whole app to an old major. That's the classic failure mode here.
• No semver discipline assumed. No changelog and a single maintainer mean silent behavior changes are possible between commits. Pin to a tag or commit hash, and only bump deliberately with your contract tests run.
• Debugging in Symfony: bin/console debug:container --show-private | grep -i kmj and debug:config kmj_toolkit are your fastest checks; a missing service usually means the extension alias or config block is wrong. In Laravel you have neither, which is another reason to go through an adapter.
• Supply-chain hygiene. A 0-star, 0-dependent package is a typosquat/compromise vector — verify the vendor, the license, and that you're pulling from the intended repo. Confirm license compatibility before code lands.
• Extension points are your escape hatch, so build them in. Wrapping behind an internal interface and a config-driven adapter is what lets you fork, patch, or delete the dependency without touching application code. Budget ongoing engineering time if you do adopt — you effectively own the fork.