Core Bundle Laravel Package

Getting Started

• Check compatibility before anything else. This bundle’s last release was September 2015, which places it in the Symfony 2.x era. Open composer.json and look at the require block for symfony/symfony / symfony/framework-bundle constraints. If you are on Symfony 4+, stop here — you will spend more time patching than integrating.
• Install into a legacy app only. Use composer require snowcap/core-bundle (or a pinned version such as dev-master#<commit>), then register the bundle in app/AppKernel.php:

  new Snowcap\CoreBundle\SnowcapCoreBundle(),
  

• Where to look first, in order:
  1. README.md — usually the only usage docs for a 2015 agency bundle.
  2. SnowcapCoreBundle.php and DependencyInjection/ — reveals the config alias (typically snowcap_core) and whether an extension class loads services.
  3. Resources/config/ — the real API surface: service definitions, tagged Twig extensions, event listeners, form types.
  4. Resources/views/ and Twig/ — shared templates/helpers you are expected to reuse.
  5. Form/, Entity/, Controller/ — base classes intended for inheritance.
• First use case: treat it as a shared “glue” bundle for an existing Snowcap-style Symfony 2 application — pulling in common Twig helpers, base controllers/entities, or form types — rather than as a standalone feature package. The quickest win is to boot the kernel, run php app/console debug:container | grep snowcap, and see which services actually become available.

Implementation Patterns

• Register once, use everywhere. Add the bundle to AppKernel for all environments (registerBundles() without env branching) so its services and Twig extensions are consistently available in dev, test, and prod.
• Inherit from base classes rather than duplicating. If the bundle ships base controllers, entities, or form types, extend them in your app bundle and override only what differs. This is the primary intended workflow for an agency “core” bundle.
• Consume Twig extensions directly. Services tagged twig.extension are auto-registered by Symfony; use the filters/functions in templates without extra wiring. Confirm names with debug:twig (or twig:debug on older versions).
• Override services through configuration, not edits. Prefer a compiler pass or an app-level service definition with the same id to replace behavior. Avoid editing files under vendor/.
• Fork-and-path-repository for fixes. Because the package is unmaintained, the sustainable pattern is:

  "repositories": [{ "type": "path", "url": "packages/core-bundle" }],
  "require": { "snowcap/core-bundle": "*" }
  

  Copy the bundle into your repo, patch it, and keep the namespace stable.
• Integration testing. Boot a test kernel that registers the bundle, then assert that expected services exist and Twig extensions render. This catches the common failure mode where the DI extension silently loads nothing.
• Gradual adoption. Since there are no dependents and no active community, integrate one feature at a time (e.g., just the Twig helpers first) and verify with a smoke test before depending on base classes.

Gotchas and Tips

• Abandoned since 2015. No security patches, no PHP 7.2+ / Symfony 3+ support guarantees. Pin the exact version and audit the code before production use. For new projects, copy the few useful classes into your app instead of adding the dependency.
• Zero dependents and 3 stars means effectively no community support. Do not expect answers to issues; read the source.
• PSR-0 vs PSR-4 autoloading. Older Snowcap bundles often use PSR-0. If you fork and convert to PSR-4, update composer.json autoload and run composer dump-autoload -o; otherwise classes will “not be found” despite existing.
• Config alias mismatch. The extension alias is derived from the bundle name (snowcap_core), but check DependencyInjection/*Extension.php — a wrong key in config.yml is silently ignored unless the extension calls processConfiguration().
• Services not loading. If debug:container shows nothing, verify the extension’s load() method and that Resources/config/services.yml is imported. A missing import is the most common “bundle does nothing” bug.
• Template override path. Override bundle templates via app/Resources/SnowcapCoreBundle/views/... (Symfony 2.x convention). In newer Symfony this path changes, another reason the bundle does not port cleanly.
• Debugging commands: debug:container --tag=twig.extension, debug:event-dispatcher, lint:yaml, and cache:clear after config changes. In Symfony 2.x these are container:debug, event-dispatcher:debug.
• Extension points: bundle inheritance (getParent()), service decoration (Symfony 2.8+), and compiler passes are the safe ways to customize. Avoid monkey-patching vendor code.
• Do not mix with modern bundles that assume autowiring or PSR-4; the DI conventions of 2015 Symfony will conflict. Keep this bundle isolated to the legacy portion of the app.