Tools Bundle Laravel Package

Getting Started

Before writing any application code, confirm what you actually installed. Despite the "Laravel developer" framing, tecnocreaciones/tools-bundle is a Symfony bundle (the Bundle suffix, the 2016 release date, and the vendor's other packages all point to Symfony 2/3-era code), not a Laravel package. There is no ServiceProvider, no facade, and no config/tools.php. If your app is Laravel, stop here and treat this as a source of copy-paste utilities rather than a dependency.

v0.2 does not change this. The release notes are Spanish and are a status marker, not a changelog: "En este punto se encuentran todos los servicios dependientes a symfony2 y al bundle, en el siguiente release las dependencias se eliminaran y se actualizarán algunos componentes." Translation: "At this point all services dependent on Symfony2 and on the bundle are [contained] here; in the next release the dependencies will be removed and some components will be updated." In other words: v0.2 is a checkpoint release with no functional change, and the author is signalling a future decoupling. Do not plan adoption around a release that doesn't exist yet — verify the actual diff (git compare v0.1...v0.2 or the tag's tree) before assuming anything landed.

If you are on Symfony (or willing to fork), the minimal path is:

1. Inspect before installing. Because the package has 1 star, 0 dependents, and no release between 2016 and this one, read the repo first:

   • composer.json → check type, require (PHP and symfony/symfony constraints), and autoload PSR mapping. Confirm whether v0.2 actually relaxed any constraint — the notes suggest it did not.
   • The bundle class (typically Tecnocreaciones\ToolsBundle\TecnocreacionesToolsBundle or similar) — this is your entry point.
   • DependencyInjection/ → the extension class and Configuration.php, which tell you the real config tree and service IDs.
   • Resources/config/services.yml (or .xml) → the actual list of services you can inject.

2. Install pinned to a compatible PHP/Symfony pair. On a modern app this will almost certainly conflict; prefer a path or vcs repository entry in composer.json over Packagist so you control the checkout, and pin the tag explicitly now that there are two:

   "repositories": [{ "type": "vcs", "url": "https://github.com/Tecnocreaciones/ToolsBundle" }],
   "require": { "tecnocreaciones/tools-bundle": "0.2.*" }
   

3. Register the bundle in config/bundles.php (Symfony 4+) or AppKernel::registerBundles() (Symfony 2/3).

4. First use case: rather than wiring the whole bundle, pick one service or trait you actually need (a helper, a base entity, a paginator, whatever the services.yml exposes), verify it with bin/console debug:container <service_id>, and inject it into a single controller. Prove value on one integration before touching the rest of the app.

Implementation Patterns

Service injection over static helpers. Legacy "tools" bundles usually expose both static utility classes and container services. Always prefer the service — static calls bypass the container, break testability, and often hide global state.

Treat config as opt-in. After registering, dump the tree with bin/console config:dump-reference <vendor>_tools (the alias comes from the DI extension's getAlias()). Only set the keys you need in config/packages/<vendor>_tools.yaml; the bundle's defaults are from 2016 and may not match your app.

Wrap, don't spread. Create thin application-level adapters so third-party types don't leak into your domain:

final class Slugger
{
    public function __construct(private \Tecnocreaciones\ToolsBundle\...\Slugger $inner) {}
    public function slug(string $s): string { return $this->inner->slugify($s); }
}

Then alias the bundle service into your adapter in services.yaml. When (not if) you replace the bundle, you change one binding. This adapter boundary is also your migration seam if the promised "next release" strips the Symfony wiring: your app keeps calling App\Support\Slugger while the internals change.

Fork-and-vendor is the realistic workflow. For an abandoned, low-adoption bundle, the highest-leverage pattern is to fork it into app/Support/ or a private tools/ package, strip the Symfony wiring you don't use, and keep only the pure-PHP logic. This eliminates version conflicts and lets you add types/tests. v0.2's roadmap note effectively describes exactly this refactor — you can do it on your own schedule instead of waiting for it.

Test in isolation. Since there are no dependents and likely no test suite in the repo, write your own characterization tests around each service you adopt before relying on it. This is also how you'll discover whether the 2016 code emits deprecations under your PHP version — and whether the v0.2 tag changed any behaviour at all.

Integration via compiler pass if you must extend. If you need to decorate or replace a bundle service globally, use a CompilerPass with setDecoratedService() rather than editing vendor code.

Gotchas and Tips

• It is not a Laravel package. No auto-discovery, no config/ publish tag, no facade. Any tutorial written for Laravel will not apply.
• v0.2 is a promise, not a port. The release notes say Symfony2 dependencies will be removed "in the following release." Until that ships, every constraint, service wiring, and bin/console instruction here still applies. Don't upgrade expecting PHP 8 / Symfony 6 compatibility — verify with composer why-not symfony/framework-bundle 6.* after pulling.
• Release notes are in Spanish and describe intent, not changes. There is no English changelog, no diff summary, and no linked PR list in the release body. Diff the tags yourself (git diff v0.1 v0.2 --stat) before assuming a fix or a new feature you depend on.
• PHP and Symfony constraints will fight you. A 2016 bundle typically requires php: >=5.5 and symfony/symfony: ~2.7|~3.0. On PHP 8.1+/Symfony 6+ expect composer why-not and deprecation noise. Use --ignore-platform-reqs only as a diagnostic, never as a permanent fix.
• PSR-0 or non-standard autoloading. Check autoload in composer.json; if it's PSR-0 or a classmap, run composer dump-autoload -o after any fork and verify classes resolve.
• Silent service failures. If the DI extension isn't loaded (wrong bundle name, missing getContainerExtension()), services simply don't exist and you get "service not found" instead of a helpful error. bin/console debug:container --show-private | grep -i tools is the fastest sanity check.
• Config key naming. The YAML root is the extension alias, which often differs from the Composer package name (tecnocreaciones_tools vs tools_bundle). Read getAlias(), don't guess.
• Debugging deprecations. Run with SYMFONY_DEPRECATIONS_HELPER=weak and bin/console cache:clear -vvv to surface which bundle paths trigger them; this tells you what to strip first when forking.
• Extension points are few but real: service decoration, compiler passes, and overriding the bundle's templates/translations via Resources/ in your own bundle (Symfony's resource override chain). There is no event system of its own.
• Security posture. Effectively unmaintained since 2016 (one status-only tag in between), 1 star, 0 dependents, no disclosed audit. Don't route user input through any of its parsing/escaping helpers without reading the source; don't ship it as a runtime dependency in anything security-sensitive. The v0.2 tag is not a maintenance signal — no security review or dependency bump accompanied it.
• Watch the repo, don't adopt early. If the promised dependency-free release lands, re-evaluate from scratch: it may finally be Laravel-usable (plain classes, no container), or it may remain a half-finished Symfony shim. Set a reminder on the repo rather than pinning dev-master in the meantime.
• The scores tell the story. Opportunity 30.83 with a 0.035 aggregate means "nobody uses it, but the category (common-app scaffolding) has demand." The right move is usually to cherry-pick functionality into your own codebase, not to adopt the package wholesale.