Embedded Call Laravel Package

Getting Started

bfg/embedded-call is a tiny utility for invoking a "feature" while passing a transformed/adjusted payload into it. Given the 1-star / 0-dependent profile, treat the source as the primary documentation — read src/ before writing production code against it.

Minimal setup:

composer require bfg/embedded-call

Then publish any config the package ships:

php artisan vendor:publish --provider="Bfg\\EmbeddedCall\\EmbeddedCallServiceProvider"

Where to look first:

1. Service provider — to see what is bound into the container and whether a facade is registered.
2. Contracts / interfaces — the package is almost certainly contract-driven; the interfaces tell you what a "feature" must implement.
3. The call/executor class — this is where "adjusted data" is actually applied, and it tells you the real signature to use.

Your first use case: define a feature class that expects a data payload, then invoke it through the package with a mutation callback:

EmbeddedCall::feature(MyFeature::class)
    ->with($order)
    ->adjust(fn (array $data) => array_merge($data, ['currency' => 'EUR']))
    ->call();

If the concrete API differs (method names, argument order), follow the executor class rather than assuming the above.

Implementation Patterns

Feature-as-a-class. The idiomatic shape is a dedicated class (or closure) that receives adjusted data and returns a result. Keep features small and single-purpose; the package is a thin dispatcher, not a framework, so responsibility for orchestration is yours.

Payload adjustment at the call site. The core value is deferring data shaping until invocation. Prefer adjusting at the boundary — a controller or job — rather than baking defaults into the feature itself. This keeps the feature reusable across contexts where adjustment differs.

Composition. Chain feature calls where one feature's output feeds another's input. Because data is adjusted per call, this is cleaner than mutating a shared array across features.

$quote = EmbeddedCall::feature(PriceQuote::class)->with($cart)->call();
$invoice = EmbeddedCall::feature(Invoice::class)
    ->with($quote)
    ->adjust(fn ($q) => ['amount' => $q['total'], 'tax' => $q['tax']])
    ->call();

Testing integration. Features that take adjusted data are straightforward to unit test in isolation; use EmbeddedCall in feature tests to assert the adjustment logic rather than the whole pipeline. Fake/spy the feature where the adjustment is the unit under test.

Container binding. If the package resolves features through the container, register feature interfaces in your AppServiceProvider so alternative implementations (e.g., a stub in tests) can be swapped.

Gotchas and Tips

• Low-signal dependency. With 1 star and 0 dependents, expect sparse docs, no community answers, and possible API churn. Pin the version in composer.json and read the CHANGELOG/git history before upgrading.
• "Adjusted data" is ambiguous. Verify whether adjustment mutates in place, returns a new payload, or merges shallowly versus deeply. Array key collisions are the most likely source of subtle bugs — test with nested arrays explicitly.
• Type coercion. If features are type-hinted (e.g., DTOs), adjusting as arrays may fail. Adjust the DTO or adjust before DTO hydration; don't mix.
• No facade? If the service provider doesn't register a facade, inject the executor contract instead of using the facade syntax above. Check config/app.php aliases.
• Debugging failed calls. Wrap invocations in try/catch and log the adjusted payload — the package likely swallows the pre-adjustment data on failure, making root-cause hard. Log both input and adjusted output at the call site.
• Extension points. Because the codebase is small, extension usually means implementing the package's contract yourself rather than relying on hooks. If a feature needs cross-cutting behavior (logging, auth, caching), wrap the call rather than modifying features.
• Production readiness. Given the low dependency signal, wrap usage behind your own thin service so that if you need to fork or replace the package later, only one class in your app changes.
• Composer conflicts. Inspect composer.json in the package for Laravel/Illuminate version constraints before requiring in an existing app; small packages sometimes lag on major versions and cause resolver deadlocks.