Data Bundle Laravel Package

Getting Started

First, the framing: imatic/data-bundle is a Symfony bundle, not a Laravel package. It ships a Bundle class, a DependencyInjection/ extension, and service definitions — not a service provider, facade, or config/data.php. Laravel's package auto-discovery will register nothing. Plan to consume it as a library, not as a first-class Laravel extension.

Minimal steps

composer require imatic/data-bundle

Then, before writing any application code:

1. Read composer.json for the symfony/* version constraints and require/require-dev. This is the single most important file for a Laravel app, because Laravel already ships several Symfony components (http-foundation, console, finder, error-handler, var-dumper). Constraint clashes here are the most likely reason the install fails or pins you to an old Laravel.
2. Read src/ and identify the entry-point classes. Anything that isn't a *Bundle.php, a DI extension, or an event subscriber is probably a plain PHP class you can instantiate directly.
3. Read DependencyInjection/Configuration.php and DependencyInjection/*Extension.php. In a thinly documented bundle, the config tree is the documentation.
4. Read the test suite (tests/). For a package with 1 star and 0 dependents, the tests are the most reliable description of intended usage.

Where to look first

• README.md (expect it to be sparse)
• DependencyInjection/Configuration.php → what is configurable
• Resources/config/services.{yaml,xml,php} → what is actually wired
• src/*Interface.php → the intended seams for extension

First use case

Pick the smallest concrete class the bundle exposes and drive it from php artisan tinker or a throwaway test with no Laravel container involved:

$thing = new \Imatic\Data\SomeConcreteClass(/* args from the constructor */);

If that works, you have a dependency you can wrap. If it only works after kernel boot (e.g., it needs a container, a RequestStack, or a bundle-registered compiler pass), stop and evaluate whether the bundle is worth the integration cost — for a single-star package, it usually isn't.

Implementation Patterns

Direct instantiation (preferred)

Most Symfony bundle classes carry no framework coupling. Use them as plain objects and bind them in a small Laravel service provider:

// app/Providers/DataBundleServiceProvider.php
public function register(): void
{
    $this->app->singleton(SomeImaticService::class, function ($app) {
        return new SomeImaticService(
            $app->make(DependencyA::class),
            config('data-bundle.option')
        );
    });
}

This keeps the bundle at arm's length and gives you a single file to delete if you swap it out.

Translating Symfony config to Laravel config

If the bundle's behaviour is controlled by its DI extension, mirror Configuration.php into a Laravel config file:

// config/data-bundle.php
return [
    'option' => env('DATA_BUNDLE_OPTION', 'default'),
];

Do not attempt to load the Symfony extension or resolve %parameter% placeholders yourself — resolve env vars in config and pass plain scalars into the constructors.

Adapter layer, not deep integration

Given the package's maturity (1 star, 0 dependents), treat it as a leaf dependency behind your own interface:

interface DataTransformer { public function transform(mixed $input): mixed; }

final class ImaticDataTransformer implements DataTransformer { /* delegates */ }

If the bundle is abandoned or a Symfony upgrade breaks it, you rewrite one class.

Testing

Use plain PHPUnit against the concrete classes. Reserve Orchestra Testbench for the adapter/provider, and only if the bundle actually touches the container.

Symfony-side pattern (for context)

If you also maintain the Symfony app this bundle targets, registration is config/bundles.php:

Imatic\DataBundle\ImaticDataBundle::class => ['all' => true],

…plus a config/packages/imatic_data.yaml matching the DI config tree, and bin/console debug:config imatic_data to verify.

Gotchas and Tips

No Laravel integration, by design. No facades, no Eloquent, no Illuminate\Contracts implementations, no publishable assets. Every integration point is hand-written. Budget for that.

Dependency conflicts are the top failure mode. Laravel pins Symfony components. If the bundle requires, say, symfony/http-kernel ^6 while Laravel ships ^7, Composer will either refuse or downgrade your framework. Always check before merging:

composer require imatic/data-bundle --dry-run
composer why-not symfony/http-kernel <version>

Pin the version. With 0 dependents there's no downstream ecosystem pressure to keep it working. Use an exact constraint ("imatic/data-bundle": "1.0.3") rather than ^1.0, so a surprise tag can't break a deploy.

Don't expect docs. A one-star bundle typically has a stub README. Treat the DI extension, service definitions, and tests as canonical. If those are also thin, that's a signal the package is a personal/internal extraction rather than a supported product.

Debugging

• Symfony: bin/console debug:container Imatic, bin/console debug:config imatic_data.
• Laravel: dd(get_class($resolved)) inside your provider binding; app()->make(SomeImaticService::class) in Tinker to confirm wiring.
• If a class throws on construction, check whether it expects a LoggerInterface, EventDispatcherInterface, or TranslatorInterface. Symfony bundles routinely type-hint PSR-3 and Symfony contracts — Laravel's Log and Event are not those interfaces. Bridge with psr/log adapters or pass null where the constructor allows it.

Extension points to look for

• *Interface.php in src/ — the intended decoration seams.
• EventSubscriberInterface implementations — re-implement these as Laravel listeners on your own events rather than booting the Symfony dispatcher.
• Compiler passes in DependencyInjection/Compiler/ — these will not run in Laravel; if the bundle depends on them for correctness, direct instantiation will silently misbehave. Check for this before adopting.

Vendor-audit the source. MIT licence means you can read and fork freely. For a package this small, a 20-minute read of src/ is cheaper than discovering a coupling problem in production. If you find yourself needing more than a thin adapter, fork it into your app/ namespace and drop the Composer dependency — you lose nothing, since there's no upstream community to track.