Comun Laravel Package

Getting Started

Reality check first. gonzakpo/comun (ComunBundle) is a 2017-era Symfony bundle with 2 stars, 0 dependents, and no release since March 2017. Before writing a single line against it, spend ten minutes deciding whether it's worth adopting at all — for most modern Symfony projects (5.x/6.x/7.x), the answer will be "no, but the ideas are reusable." If you're maintaining a legacy Symfony 2.x/3.x app that already depends on it, the guidance below applies directly.

Minimal steps to evaluate:

1. composer require gonzakpo/comun in a throwaway project (or clone the repo) — the package metadata alone won't tell you what you're getting.
2. Open the bundle's DependencyInjection/ directory first. The extension class and its Configuration tree are the fastest map of what the bundle actually offers — every service definition and config key passes through there.
3. Check Resources/config/services.yml (or XML) next. That file enumerates the concrete services you can autowire or fetch from the container.
4. Read comun/src/ComunBundle.php (the bundle class itself) — if it's empty, the bundle is purely a service/config carrier with no compiler passes, which is the simplest and most common case for "common" bundles.

First use case. Treat it as a grab-bag of Symfony boilerplate reducers — typically things like base controllers, form type extensions, Doctrine helpers, Twig extensions, or utility services for date/string handling. Pick one service you actually need, verify its code path, and wire it in. Do not adopt the whole bundle wholesale; with 0 dependents there's no community pressure keeping any single piece healthy.

If it doesn't install cleanly against your Symfony version (highly likely on 5.4+), stop. Port the one class you wanted into your own App\Util namespace — it's usually <100 lines and removes the baggage entirely.

Implementation Patterns

Register the bundle explicitly (Symfony <4 style). This bundle predates Symfony Flex, so there's almost certainly no recipe. You'll need:

// config/bundles.php (Symfony 4+) or AppKernel.php (Symfony 2/3)
return [
    // ...
    Gonza\ComunBundle\ComunBundle::class => ['all' => true],
];

Verify the exact namespace from composer.json's autoload section — old bundles often have a namespace that doesn't match the Composer package name (gonzakpo/comun vs. whatever the PHP namespace is).

Service usage — prefer injection over container access. Once registered, the bundle's services are in the container like any other. Use constructor injection with type hints:

use Gonza\ComunBundle\Service\SomeHelper; // verify the real FQCN

class ReportController
{
    public function __construct(private SomeHelper $helper) {}
}

If a service isn't public: false-friendly (2017 bundles frequently left services public), you may need to rely on $container->get() — but inject wherever you can so the dependency stays visible.

Configuration pattern. If the bundle exposes a config tree, it will be under a root key matching the bundle's alias (commonly comun:). Check the Configuration class for the alias and available keys. Override defaults in config/packages/comun.yaml (or config.yml on older Symfony):

comun:
    # keys discovered from the Configuration class
    some_option: true

Integration tip — wrap it. Because the bundle is unmaintained, put a thin adapter around anything you use:

final class AppSlugger
{
    public function __construct(private $comunSlugger) {}

    public function slug(string $text): string
    {
        return $this->comunSlugger->slugify($text);
    }
}

When you eventually remove the bundle, you swap one adapter rather than hunting call sites. This is the single highest-value pattern for consuming abandoned code.

Testing pattern. Don't write integration tests that boot the whole bundle. Instantiate the individual service classes directly in unit tests — with 0 dependents and no CI history, the services may have untested edge cases, and you'll want fast feedback while you confirm behavior.

Gotchas and Tips

• PHP version drift. Code from 2017 may use create_function, string-based callables, or Symfony 2.x APIs (getMock, ContainerAware, etc.) that are removed in PHP 8 and Symfony 5+. Run a static analysis pass (phpstan, rector) before committing — it's cheaper than debugging a runtime fatal in production.
• Deprecation noise. On Symfony 4.x, expect a flood of deprecation warnings from the bundle's service definitions. Suppress them in dev only; don't let them mask your deprecations.
• Autoloading namespace mismatches. Classic old-bundle trap: composer.json autoload.psr-4 says one namespace, the use statements in docs say another. Trust the autoload block.
• No recipe = manual wiring for every project. There is no Flex recipe, so every new environment (CI, staging, a new dev's machine) needs the same manual bundle registration. Document it in the repo README, not in a wiki.
• Debugging service resolution. When something "isn't there," run bin/console debug:container --show-private | grep -i comun — on pre-4.0 Symfony use bin/console container:debug. If nothing appears, the extension isn't loading the config file (check the path in Extension::load()).
• No security advisories, but no fixes either. With zero dependents, a CVE in a transitive dependency or the bundle itself will never be patched here. Vendor the code (App\Legacy\Comun) if you must keep it, so you can patch locally.
• Extension point you can still use. If you need to change one service's behavior without forking, write a compiler pass that decorates the bundle's service ID. It's the cleanest way to "patch" unmaintained code:

final class ComunPatchPass implements CompilerPassInterface
{
    public function process(ContainerBuilder $container): void
    {
        if ($container->hasDefinition('comun.some_service')) {
            $container->getDefinition('comun.some_service')
                ->setClass(MyFixedVersion::class);
        }
    }
}

• Migration tip. When you're ready to drop the dependency, grep -r 'ComunBundle\|comun\.' src/ config/ gives you the full footprint. Given the bundle's size, a migration is typically an afternoon, not a sprint — factor that into the adoption decision up front.