Lib Bundle Laravel Package

Getting Started

Reality check first. This bundle has 0 stars, 0 dependents, and a low health score. Treat it as an internal/legacy library that Whatson Web used across their own client projects, not a maintained community package. There is likely no documentation, no tagged releases, and no upgrade path. The first step is not composer require — it's reading the source.

1. Clone and inventory it.

   git clone https://github.com/whatson-web/LibBundle
   cd LibBundle
   cat composer.json        # Symfony version constraints, package type, autoload
   find . -maxdepth 3 -type f | head -50
   

   Look first at composer.json (type must be symfony-bundle for auto-discovery), then src/ (or the root namespaces), DependencyInjection/, Configuration.php, and Resources/config/services.yaml. A generic "LibBundle" is usually a grab-bag of helper services, Twig extensions, and traits.

2. Install into a scratch Symfony app, not production:

   composer config repositories.libbundle vcs https://github.com/whatson-web/LibBundle
   composer require whatson-web/lib-bundle:dev-master
   

   If it won't resolve, clone it into packages/lib-bundle and use a path repository instead.

3. Register the bundle if auto-discovery doesn't fire (check for a WhatsonWeb\LibBundle\LibBundle class and confirm type: symfony-bundle in composer.json):

   // config/bundles.php
   WhatsonWeb\LibBundle\LibBundle::class => ['all' => true],
   

4. Verify what you actually got:

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

First use case: pull out the utility helpers you actually need (string/array/date formatting, traits, Twig filters) and validate them against a scratch app before wiring anything into your real project. The most likely outcome is that you cherry-pick 20 lines of logic rather than depend on the bundle.

Implementation Patterns

Cherry-pick over dependency. For a 0-star bundle, the highest-leverage pattern is extraction: copy the helper classes you need into App\Util\…, keep the license header, and drop the composer dependency. This removes the upgrade/security risk entirely.

If you must depend on it, wrap it. Create thin adapter services in your own namespace so your code never imports the vendor classes directly:

namespace App\Util;

use WhatsonWeb\LibBundle\...\SomeHelper;

final class TextFormatter
{
    public function __construct(private SomeHelper $inner) {}
    public function format(string $s): string { return $this->inner->format($s); }
}

When the bundle rots, you swap one class.

Pin by commit SHA, not a branch. With no tags there is no semantic version to trust:

"require": { "whatson-web/lib-bundle": "dev-master#abcdef1234567890" }

Local development with path repository. If you plan to patch the bundle, mirror it into packages/ and reference it with a path repository + symlink:

"repositories": [{ "type": "path", "url": "packages/lib-bundle", "options": { "symlink": true } }],
"require": { "whatson-web/lib-bundle": "*" }

Twig integration. If it ships Twig extensions, they're typically registered in Resources/config/services.yaml with twig.extension tags. Confirm with bin/console debug:twig and check for filter/function name collisions with your existing extensions.

Test the utilities in isolation. The helper classes are usually plain PHP with no container deps — instantiate them directly in PHPUnit and assert behaviour before trusting them in your app:

$helper = new SomeHelper();
$this->assertSame('...', $helper->format('...'));

Fork for longevity. If the bundle is load-bearing, fork it into your org, add a LICENSE check, bump constraints, and treat it as an internal package. That gives you composer require yourorg/lib-bundle with a commit you control.

Gotchas and Tips

• Symfony version drift. The composer.json constraints almost certainly target Symfony 3/4/5. Attempting install on Symfony 6/7 will likely fail on deprecated APIs (ContainerAwareCommand, RequestStack usage, getBlockPrefix, etc.). Check the symfony/* constraints before committing.
• Autoload namespace mismatches are common in older bundles — psr-4 may map WhatsonWeb\LibBundle\ to src/ while classes actually live elsewhere. Run composer dump-autoload -o and inspect errors.
• Extension alias must match. The DependencyInjection/Configuration.php getAlias() and the extension name must match the bundle shorthand (lib). If it complains about missing config, bin/console debug:config lib will reveal required nodes.
• Private services. Older bundles often register services as public: false or, conversely, still rely on $container->get('...'). Use debug:container and constructor injection; avoid service locator patterns.
• services.yaml overrides work best for extension points — redefine a service ID in your app config to replace a bundle service. This is the safest customisation hook without forking.
• No releases = no security advisories. You are the maintainer by default. Run composer audit after install and check LICENSE exists; if absent, treat as all-rights-reserved and ask before using commercially.
• Debugging: bin/console debug:container --tag=twig.extension, bin/console debug:event-dispatcher, and bin/console about are your first stops. APP_DEBUG=1 will surface deprecation warnings (via symfony/phpunit-bridge or the deprecation log) that indicate what's already broken.
• Don't upgrade blindly. With no dependents there's no compatibility signal — validate every change against your own test suite. Keep a CHANGELOG.md in your fork if you patch it.
• Compiler passes in DependencyInjection/Compiler/ may assume container state that doesn't exist in your app; if the container throws during compile, --verbose on cache:warmup will point to the pass.