Sftools Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — there is no ServiceProvider, no config/sftools.php, and no facade. Before installing anything, confirm you actually need it: last tagged release is from early 2018, it has essentially no adoption, and its dependency constraints almost certainly target Symfony 2.x/3.x era PHP. If you're on a modern Laravel stack, the realistic path is to read the source and copy the handful of helper classes you need, not to composer require the bundle.

If you still want to evaluate it directly:

1. Inspect the repo first: composer.json (PHP/Symfony version constraints), DependencyInjection/ (what services get registered), Resources/config/ (service definitions), Twig/ or Helper/ (the actual useful logic), and Form/Type/ (widgets).
2. In a Symfony app: composer require rodgermd/sftools-bundle and register Rodger\SfToolsBundle\RodgerSfToolsBundle in AppKernel::registerBundles() (or config/bundles.php on Symfony 4+, where it will likely fail on version constraints).
3. In a Laravel app: do not try to boot the bundle. Pull the class files into app/Support/SfTools/, fix namespaces, and register the ones you need in a small service provider.

Your first useful use case is almost always the Twig/helper utilities — render one of the provided widgets or call one helper in a template (or, in Blade, wrap the helper in a directive) to confirm the class actually works on your PHP version. Build that single vertical slice before wiring anything else.

Implementation Patterns

Treat it as a source of utilities, not a framework integration. The bundle bundles unrelated "tools and widgets"; cherry-pick.

• Service wiring (Symfony): the bundle's DependencyInjection/*Extension.php loads Resources/config/services.*. After registering the bundle, run bin/console debug:container --show-private | grep -i rodger to see what actually got registered — this is the fastest way to learn the public surface.
• Twig extensions: if a Twig\Extension\* class exists, register it explicitly rather than relying on the bundle's autoconfiguration (which was written before autoconfigure existed):

  services:
      Rodger\SfToolsBundle\Twig\SomeExtension:
          tags: [twig.extension]
  

• Widgets / form types: use them as standard form types (->add('field', SomeWidgetType::class)), then override their templates via Resources/views/ overrides in your app, which is the cleanest extension point this bundle offers.
• Porting a helper to Laravel: wrap it in a thin adapter.

  // app/Providers/SfToolsServiceProvider.php
  public function register(): void
  {
      $this->app->singleton(\App\Support\SfTools\SomeHelper::class, fn () => new \App\Support\SfTools\SomeHelper());
  }
  

  For template helpers, expose them via a Blade directive:

  Blade::directive('sftool', fn ($expr) => "<?php echo app(\App\Support\SfTools\SomeHelper::class)->render($expr); ?>");
  

• Workflow tip: write a one-file characterization test (assertSame on the helper's output for a known input) immediately after copying any class. These old bundles have zero tests and undocumented edge behavior; the test is your only regression net before you start editing namespaces and type hints.
• Pin and vendor: if you must keep the dependency, fork it into your VCS and reference it as a path or VCS repository. That gives you the ability to patch PHP-version incompatibilities without fighting an unmaintained upstream.

Gotchas and Tips

• It's not a Laravel package. Composer will install it, but nothing auto-discovers. Any guide assuming php artisan vendor:publish does not apply. Plan for manual wiring or extraction.
• PHP/Symfony version wall is the first blocker. An early-2018 bundle will target PHP 7.0–7.2 and Symfony 2.8/3.x. On PHP 8.x expect fatals from removed features (each(), create_function, implicit nullable parameters, getMock() in any bundled tests). Run composer why-not php / check the constraint before wasting time.
• Abandonment risk. Two stars, zero dependents, no release since 2018. Treat it as unmaintained: no security patches, no compatibility fixes. Do not put it on a critical path.
• Namespace and autoload surprises. Old bundles often use PSR-0 or a non-standard namespace (Rodger\SfToolsBundle\...). After copying files, run composer dump-autoload -o and verify with php -r "class_exists('...');" before assuming a silent failure is a logic bug.
• Silent template failures. Widgets that ship Twig templates will fail with a confusing "template not found" if the bundle's Resources/views path isn't registered. On Symfony 4+, verify the bundle path is actually in the Twig loader paths; on a port, copy the templates into resources/views/vendor/sftools/.
• Debugging the container: debug:container --tag=twig.extension and debug:container --parameter are your friends — old bundles frequently register services under generic IDs that collide with your own.
• Config quirks: many bundles of this vintage read config from config.yml with no validation and no defaults. If a helper returns null unexpectedly, check whether an Extension::load() default is missing rather than debugging the helper itself.
• Best extension point is the template layer. Overriding views (Symfony bundle inheritance / copying into your app) is far safer than subclassing services, because the service classes were never designed for extension and are typically final-less but non-injectable.
• Verdict for day-to-day use: budget an afternoon to extract the 1–2 utility classes you actually want, add tests, and drop the dependency. Keeping the bundle installed for the sake of two helpers is a maintenance liability with no upside.