Tool Utils Bundle Laravel Package

Getting Started

Install and register

composer require sfynx-project/tool-utils-bundle

Register the bundle in config/bundles.php (Symfony 4+/5+):

return [
    // ...
    Sfynx\ToolBundle\SfynxToolBundle::class => ['all' => true],
];

If you are on an older Sfynx application the bundle is typically already pulled in transitively by sfynx-project/application — check app/AppKernel.php before adding it twice.

Where to look first

1. src/ — the bundle's PHP namespace mirrors the Composer autoload; the useful code lives under Utils/, Service/, Extension/ (Twig) and DependencyInjection/.
2. DependencyInjection/Configuration.php — this is the authoritative list of every sfynx_tool: config key, not the README (which on this project is usually thin or outdated).
3. Resources/config/services.yml / services.xml — shows which utilities are registered as services versus which are plain static helper classes. That distinction drives the whole usage model.

First use case

The most common day-to-day entry point is the static string/date/slug helpers. They are callable with zero wiring:

use Sfynx\ToolBundle\Util\Formatter\StringUtils;

$slug = StringUtils::slugify('Héllo World!');

Start by wiring one of these into a controller or a Twig filter and confirm the autoload path resolves. If you cannot find the exact class name, run:

grep -r "function " vendor/sfynx-project/tool-utils-bundle/src --include="*.php" | grep -i "slug\|date\|string"

Implementation Patterns

Pattern 1 — Static utilities inside a service wrapper

The bulk of the bundle is static helper classes (StringUtils, DateUtils, array/JSON helpers, crypto/encoding helpers). Because they are static, the pragmatic move is to wrap only the ones you actually use behind your own injectable service:

final class TextTools
{
    public function slug(string $value): string
    {
        return StringUtils::slugify($value);
    }
}

This keeps your domain code mockable while still benefiting from the bundle's edge-case handling (accents, unicode, transliteration tables).

Pattern 2 — Twig filters/extensions

The bundle ships Twig extensions for the same helpers. Enable them (usually automatic once the bundle is registered, occasionally gated behind a config flag) and use filters directly in templates:

{{ article.title|sfynx_slug }}
{{ entity.createdAt|sfynx_date_format('d/m/Y') }}

Prefer this over pre-formatting in the controller — it keeps presentation logic where reviewers expect it. Confirm the exact filter names by inspecting Twig/Extension/*.php.

Pattern 3 — Media and filesystem helpers

If you use the media/file utilities, the standard wiring is a two-step call: configure a storage path once in config/packages/sfynx_tool.yaml, then pass a path (or uploaded file) into the helper and let it derive the target. Keep relative paths in config so the same code runs across environments.

Pattern 4 — Composition with other Sfynx bundles

This bundle is a leaf dependency; other Sfynx bundles (auth, media, template) call into it. If you are already running a Sfynx application, treat the public static methods as an internal API and don't redeclare your own equivalents — the whole point of adding it is consistency with sibling bundles. Conversely, in a plain Symfony app, cherry-pick rather than trying to adopt the whole stack.

Workflow suggestion

Because usage is low and the package is effectively in maintenance mode, adopt it per-helper: write a thin facade over each helper you use, add a couple of unit tests pinning the expected output (especially for slugification and date formatting, which are locale-sensitive), and you gain a buffer against a future fork or replacement.

Gotchas and Tips

• License is NOASSERTION. Composer reports the license field as unparseable. Before shipping commercially, open LICENSE in the package root and confirm the actual terms manually. A legal review is the single biggest blocker here — don't let it surface at release time.
• Static methods are untestable directly. PHPUnit cannot mock StringUtils::slugify(). Always go through your facade (Pattern 1) if you need assertions or want to swap the implementation later.
• Namespaces drift between versions. Sfynx bundles have been reorganized multiple times (Sfynx\ToolBundle\... vs older Sfynx\ToolBundle\Util\...). If a use statement fails, inspect the actual directory tree in vendor/ — the README likely doesn't match the installed version.
• Config key mismatch is the usual source of "silent" failures. Configuration.php may be under Configuration/ at the bundle root or in DependencyInjection/; read the real file rather than trusting docs. Config values are generally optional and default to null, so a missing key fails quietly rather than throwing.
• Locale and ICU sensitivity. Slug and date helpers can produce different output depending on the active intl extension and application locale. Pin the locale in tests (Locale::setDefault('en')) or you'll get red builds on CI machines with different ICU versions.
• Optional system binaries. Media/PDF/image helpers often shell out to imagick, ghostscript or zip. Check php -m and the container before debugging PHP — the failure mode is usually a missing extension, not a bug.
• Debugging helpers quickly. There is no dump() server here. Use php -r with a one-liner require of the Composer autoload to exercise a static helper outside Symfony; it isolates whether the bug is in the helper or in your wiring.
• Extension point: your own Twig extensions. If you need behavior the bundle doesn't cover, register your own Twig extension alongside it rather than forking. Forking means you inherit the maintenance burden of an effectively unmaintained package (1 star, 0 dependents).
• Pin the version. With no active release cadence, use an exact constraint ("sfynx-project/tool-utils-bundle": "~2.14" or the specific tag you validated) rather than ^, so a surprise push doesn't silently change behavior in CI.