Getting Started

1. Check compatibility before you install. The last tagged release is from April 2017 and the package has zero dependents on Packagist, so its composer.json almost certainly pins symfony/symfony or the individual components to ~2.8|~3.0 and PHP to >=5.5. Run:

composer require tps/util-bundle --dry-run

and read the constraint conflict output before committing. If you are on Symfony 4+, you will need --ignore-platform-reqs at best, or a fork at worst.

2. Register the bundle. On the era it targets:

// app/AppKernel.php
$bundles = [
    // ...
    new Tps\UtilBundle\TpsUtilBundle(),
];

On Symfony 4/5 (if you forced the install):

// config/bundles.php
return [
    Tps\UtilBundle\TpsUtilBundle::class => ['all' => true],
];

3. Look here first, in this order:

README.md in the repo — with 1 star and no docs site, this is the only narrative documentation you get.
src/ — the bundle is "generic utils", so the real value is a handful of plain classes (string/array/date helpers, possibly a controller or request helper). Read the source; there is no API doc.
Resources/config/services.xml (or .yml) — this tells you which helpers are registered as services and under what IDs.
DependencyInjection/ — the bundle's configuration tree and parameters.

4. Discover the services you actually got:

bin/console debug:container tps --show-private
bin/console debug:twig | grep -i tps
bin/console debug:event-dispatcher | grep -i tps

On Symfony 2.8/3.x all services are public, so $container->get('tps.util.something') works directly. On 3.4+ they may be private — use the --show-private flag to find them, then inject them by type instead.

5. First use case. Pick exactly one helper you need — typically a formatter or a string/array utility — wire it into a single service, and leave the rest of the bundle untouched. Do not adopt "the bundle" wholesale; adopt one class at a time.

Implementation Patterns

Favour the plain classes over the services. Bundles of this shape (2017, "generic utils", 1 star) usually contain classes with no dependencies — static-ish helpers that take primitives and return primitives. If a class has no constructor dependencies, instantiate it directly:

use Tps\UtilBundle\Util\StringUtil;

$slug = StringUtil::slugify($title);

This is testable, has no container coupling, and survives a Symfony upgrade.

Inject when the class is a real service. If the registry says it is wired, inject by type via the constructor rather than pulling from the container:

class ArticleService
{
    private $utils;

    public function __construct(\Tps\UtilBundle\Util\Whatever $utils)
    {
        $this->utils = $utils;
    }
}

Autowiring will only work if the service is properly aliased. If debug:container shows a service ID but autowiring fails, add the alias yourself in config/services.yaml:

services:
    Tps\UtilBundle\Util\Whatever:
        alias: tps.util.whatever
        public: true

Wrap it behind your own interface. Given the maintenance risk, the strongest pattern is a one-class adapter:

interface Slugs { public function from(string $title): string; }

final class TpsSlugs implements Slugs
{
    public function from(string $title): string
    {
        return StringUtil::slugify($title);
    }
}

Two years from now when you drop the dependency, you rewrite one file instead of grepping for Tps\.

Twig extensions. If the bundle ships one, it is registered automatically; use it in templates only after confirming with debug:twig. If you need to disable it, there is usually no config toggle — remove it from the service definition via a compiler pass or a services.yaml override.

Config-driven parameters. Older bundles expose settings under tps_util: in config.yml. Dump the resolved tree:

bin/console config:dump-reference tps_util

Set defaults there rather than hardcoding them in your own services.

Testing pattern. Because these helpers are usually pure, test them without the kernel:

public function testSlug(): void
{
    $this->assertSame('hello-world', StringUtil::slugify('Hello World'));
}

Add an integration test only for the service wiring — a KernelTestCase that boots the bundle and asserts the container resolves the alias.

Migration tip. If you need to move to Symfony 5/6, the cheapest path is often composer remove plus copying the two or three src/Util/*.php files you use into app/Utils/. They are MIT-licensed (check LICENSE) and dependency-free, so this is usually less work than maintaining a fork.

Gotchas and Tips

Version constraints will bite you. Last release 2017 means the constraints are frozen at symfony/* ~2.8|~3.0 and likely php >=5.5. Composer will resolve or fail; if it fails, a fork with relaxed constraints is the only clean fix. Do not spend an afternoon fighting --ignore-platform-reqs in production.

The bundle is effectively unmaintained. No dependents, no issue activity, no releases since 2017. Treat every class as vendored code: you own the bugs now. Pin the exact version in composer.json (no ^) so a stray tag cannot change behaviour silently.

Deprecations on modern Symfony. You will see The "Tps\UtilBundle\..." service is private and TreeBuilder::root() must be configured warnings. These are harmless but noisy; they also break on Symfony 5+ where the old DefinitionDecorator and ContainerAware patterns are removed entirely.

Public service removal. In Symfony 4.0+, services are private by default. Anything the bundle registered as public in 2017 may now be inaccessible via $container->get(). Prefer constructor injection, and if a service truly must be public, add public: true to a local override rather than editing vendor/.

Config key names are inconsistent. Older bundles mix tps_util, tps.util, and tps-util in extension aliases, YAML keys, and service IDs. Confirm the real alias with debug:config before writing YAML:

bin/console debug:config tps_util

Debugging checklist when a helper "doesn't work":

debug:container <id> → does the service exist and is it the class you expect?
debug:twig → is the extension loaded?
debug:event-dispatcher → if it registers listeners, are they attached?
Check Resources/config/ for XML vs YAML — the bundle may ship both, and one may be stale/broken.

Extension points to use instead of editing vendor:

Service decoration — decorates: tps.util.foo in services.yaml to wrap a helper with your own caching or logging.
Compiler pass — remove or replace a definition the bundle registers unconditionally.
Local override of the service file — in Symfony 4+, config/services.yaml definitions win over bundle-supplied ones when IDs match. Re-declare the service with your own class.
Fork + VCS repository — for a package this small and this quiet, a fork with relaxed constraints is a legitimate, low-cost move. Add it via "repositories": [{"type": "vcs", "url": "..."}].

Do not rely on its tests. With 1 star and no dependents, the CI badge (if any) is likely for PHP 5.6/7.0 against Symfony 3.0. Your own tests around the two or three helpers you use are the only meaningful safety net.

Cost/benefit sanity check. For generic utilities, symfony/string, symfony/options-resolver, and ramsey/uuid (or Str in Laravel) cover most of what a 2017 utility bundle offers, are actively maintained, and are already transitive dependencies. Before adopting tps/util-bundle, scan its src/ and ask: "do I need more than one of these?" If not, copy that one class.

Util Bundle Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips