Core Application Bundle Laravel Package

Getting Started

First, a reality check: this is a Symfony bundle, not a Laravel package. imanaging-document/core-application-bundle ships a Bundle class and Symfony DI configuration, so composer require inside a Laravel app will install code that Laravel never boots. Its stated purpose is a "Core application Bundle" — likely an internal foundation layer (base services, shared config, common commands) extracted from a larger Symfony application. With 2 stars, 0 dependents, and a maintenance history that stopped in June 2022 before a single-line v2.0 bump, treat this as reference material or a porting source, not a dependency.

What v2.0 tells you: the entire release note is "Version compatible symfony 5." That is a narrowing statement, not a feature release. Read it as: the maintainer dropped older Symfony support to land on Symfony 5, then tagged a major version for it. Two consequences follow immediately — the version number carries no semver signal you can rely on (a major bump for a compatibility tweak means future bumps are equally unpredictable), and the ceiling is now explicit: Symfony 5, which reached end of life in November 2024. There is no v2 changelog, no upgrade guide, and no mention of Symfony 6 or 7. Budget accordingly.

If you are already on Symfony 5, or evaluating whether to port it:

composer show imanaging-document/core-application-bundle --all

Then read, in this order:

1. composer.json — confirm the actual symfony/* constraints v2.0 ships. The release note says "Symfony 5" but the file says ^5.4, ~5.0, or something looser; that difference decides whether Composer will even resolve alongside your other packages.
2. README.md — often absent or thin; if it's missing, the bundle is undocumented and v2.0 added no docs.
3. src/ — look for <Vendor>\CoreApplicationBundle.php (the bundle class), DependencyInjection/*Extension.php, DependencyInjection/Configuration.php, and Resources/config/services.yaml.
4. DependencyInjection/Configuration.php — the config tree is the real API. It tells you every option the bundle expects and which are required.
5. Resources/config/ — service definitions, tags, and any compiler passes registered in the bundle's build() method.

Because v2.0 is undocumented, diff it against v1.x before trusting it. If you have a reference copy of the previous release, run a directory diff; if not, pull the tags:

composer require imanaging-document/core-application-bundle:1.* --no-scripts
# copy vendor/ aside, then
composer require imanaging-document/core-application-bundle:2.* --no-scripts
diff -ru old/ new/

A one-line release note for a major version almost always means the real changes are in composer.json and a handful of service definitions, not in behavior. Verify that assumption rather than inheriting it.

First use case: identify a single concrete capability in src/ (a service, a console command, an event subscriber) and decide whether you want to (a) depend on the bundle, (b) copy that class into your app, or (c) reimplement it. For a Laravel developer, (b) and (c) are almost always the right call — the value is the logic, not the Symfony wiring. v2.0 does not change that calculus; it slightly strengthens it, because the code you'd copy is now pinned to an EOL framework generation.

If you do install it in Symfony 5:

// config/bundles.php
return [
    // ...
    ImanagingDocument\CoreApplicationBundle\CoreApplicationBundle::class => ['all' => true],
];

# config/packages/core_application.yaml
core_application:
    # mirror the keys from DependencyInjection/Configuration.php

Then validate with bin/console debug:container and bin/console debug:config core_application.

Implementation Patterns

Day-to-day, on Symfony 5 (if you keep it):

• Inject, don't reach. All behavior should come through constructor injection of services the bundle registers. Avoid $container->get(); Symfony 5 makes services private by default, and the bundle almost certainly defines its services as private.
• Use tags as extension points. If the bundle registers compiler passes or tag names (check build() and the services.yaml for tags:), the intended pattern is that you implement an interface, tag your service, and let the bundle aggregate it. This is the correct way to extend it without forking.
• Decorate rather than modify. If you need to change behavior of a bundle service, wrap it:

services:
    App\Service\MyDecorator:
        decorates: 'core_application.some_service'
        arguments: ['@.inner']

• Override config per environment in config/packages/{env}/core_application.yaml. Verify every key against the Configuration class first; Symfony will throw on unknown keys.
• Consume its commands/events last. Run bin/console list and grep for the bundle namespace before assuming a command exists.
• Treat the version bump as a migration, not a patch. Even with a trivial release note, move to v2.0 on its own branch with composer why-not clean and your test suite green before merging anything else. If you cannot produce that, stay on v1.x and record why.

Porting to Laravel (the more likely path):

Map the Symfony concepts one-to-one, because the bundle is small enough to translate rather than adapt:

Concrete workflow:

1. Copy the behavior classes (services, value objects, commands) into app/ under a namespaced directory. Rename namespace from ImanagingDocument\... to App\....
2. Create config/core_application.php from the Symfony Configuration tree — same keys, same defaults, wrapped in env() where it maps to deployment config.
3. Write a single CoreApplicationServiceProvider that binds interfaces to implementations and registers commands. Keep bindings explicit; do not auto-scan.
4. Replace Symfony's EventDispatcher usage with Laravel's Event/Listener, and Command with Illuminate\Console\Command.
5. Add tests for each ported class before deleting the original reference. This package has essentially no community verification, so you are the test suite.

Two porting details specific to Symfony 5-era code, which is what v2.0 gives you: the bundle may still rely on annotations rather than PHP 8 attributes for routing/DI, and it may type-hint Symfony\Component\HttpFoundation\Request in ways that don't translate to Laravel's request lifecycle. Strip both before you judge whether the business logic is worth keeping — those are the two places where "copy the class" turns into "rewrite the class."

Integration tips regardless of platform:

• Pin the exact version if you depend on it: "imanaging-document/core-application-bundle": "2.0.0" — not ^2.0. A package that jumped a major version for a one-line compatibility note has given you no reason to trust its minor bumps.
• Vendor the source into a third_party/ path repo if you need it long-term and want to patch it. Given the Symfony 5 ceiling, you will be patching.
• Add a short internal ADR documenting why you depend on it, why v2.0 specifically, and what would make you remove it. With 0 dependents, nobody upstream will notice if it breaks.

Gotchas and Tips

• It is not a Laravel package. There is no service provider, no facade, no config/ publish tag. v2.0 did not change this — there is still no Laravel integration path. Any guide implying otherwise is wrong. Budget for a port, not an install.
• v2.0 caps you at Symfony 5, which is EOL. Symfony 5.4's security support ended in November 2024. Depending on this bundle therefore means either running an unsupported framework or maintaining a fork that moves it forward yourself. If your app is on Symfony 6 or 7, this package is not an option at all — check composer.json constraints and expect composer why-not to refuse resolution.
• A major bump with a one-line note means semver is decorative. v2.0 was tagged for a compatibility declaration, not an API change. Do not infer stability, do not infer that 2.1 will be backward compatible, and do not assume the maintainer has an upgrade path in mind. Read the diff.
• Undocumented config is still the biggest risk. The Configuration class is your only contract. Read it line by line; missing a required node produces a confusing InvalidConfigurationException at container compile time, not at runtime.
• Service visibility. Symfony 5 makes bundle services private by default. $container->get('core_application.*') will fail in a controller. Inject instead, and if you must fetch by id, alias it public in your app config.
• Abandonment signals, now sharper. 2 stars, 0 dependents, a three-year gap, and then a single-line release that only narrows framework support. Assume no security patching. Run composer audit after install and treat any advisory as "patch in your fork."
• Autoload surprises. Internal bundles sometimes use PSR-0 or nonstandard namespaces. A v2.0 that touched only composer.json is exactly the kind of release that gets an autoload namespace or path subtly wrong. Confirm the autoload map matches the directory layout before debugging "class not found."
• Debugging order when something doesn't work: debug:container --tag=<tag> → debug:config core_application → debug:event-dispatcher → debug:router (if it registers routes). Nine times out of ten the issue is config, not code — and after a version bump, check debug:config first, because a renamed or dropped node surfaces there.
• Extension points to look for: compiler passes in build(), tag names in services.yaml, and interfaces in src/ that are meant to be implemented. Those are the sanctioned customization hooks; anything else you change is a fork.
• License. MIT is permissive — you can copy and modify — but verify the headers in individual files. MIT on the repo does not automatically clear third-party code pasted in.
• Recommendation: unchanged, and reinforced by v2.0. Do not add this to a production Laravel dependency graph; the new release is narrower and no better maintained than the old one. Clone it, read it in an hour, port the useful 10–20% into app/, and move on. The maintenance cost of an EOL-targeted Symfony bundle with no community vastly exceeds rewriting a handful of service classes.