Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Opensoft Epl Bundle Laravel Package

opensoft/opensoft-epl-bundle

Opensoft EPL Bundle is a Symfony bundle that packages EPL integration for PHP applications. It provides bundle configuration and service wiring so teams can add EPL support with minimal setup, keeping EPL-related services organized and reusable across Symfony projects.

View on GitHub
Deep Wiki
Context7

Getting Started

This is a Symfony bundle, not a Laravel package. As a Laravel developer you should treat it as a reference implementation rather than something you install. The actual value lives in the underlying epl library it wires up.

  1. Inspect, don't install. Run composer show opensoft/opensoft-epl-bundle --all (or read the repo's composer.json) and find:
    • the transitive dependency that is the real EPL library (the "epl" in the description),
    • the PHP constraint (almost certainly ^5.6 || ^7.0) and Symfony version bounds — these usually block install on modern PHP 8/Laravel anyway.
  2. Read these four files first, in order. They are the entire public surface you'll be re-implementing:
    • OpensoftEplBundle.php — the bundle class (useless to you, but shows what it registers),
    • DependencyInjection/Configuration.php — the config tree, i.e. every option the bundle exposes,
    • DependencyInjection/*Extension.php — how config maps to service definitions,
    • Resources/config/services.{yml,xml} — service IDs, constructor args, and tags (the listener/engine wiring).
  3. First use case. Install the base EPL library directly, bind the engine as a singleton in a ServiceProvider, register one statement ("count events per user in a 5-minute window"), push a single event from a queued job, and assert a listener fires. That end-to-end loop is your proof the library is usable without the bundle.

Implementation Patterns

  • Wrap, don't inherit. Create EplServiceProvider that binds the engine and a statement registry as singletons, and a thin Epl facade. Do not attempt to register a Symfony Bundle in Laravel — it will never boot.
  • Config over DI XML. Translate the bundle's config tree into config/epl.php, with env()-driven defaults. Statements, windows, and listener classes belong in config, not in code.
  • Boot-time statement compilation. Register statements in the provider's boot() (or a dedicated StatementRegistrar), so the engine is ready before the first event arrives.
  • Ingestion via jobs. A IngestEvent queued job resolves the engine and feeds the event. Matched rules dispatch a first-class Laravel event (EplMatch), which the rest of your app handles with normal listeners. This keeps the EPL layer at the edge.
  • Mirror Symfony tags with Laravel tags. Where the bundle uses tagged services / compiler passes for listeners, use $this->app->tag([...], 'epl.listener') and $this->app->tagged('epl.listener'). Same pattern, Laravel idiom.
  • If you truly need the bundle, run it as a standalone Symfony service and talk to it over a queue or HTTP. Never co-locate it with a Laravel app.

Gotchas and Tips

  • Abandoned since Jan 2018, 1 star, 0 dependents. Assume no security fixes, no PHP 8 compatibility, and conflicting constraints with anything current. Pin the base library and plan a replacement.
  • Package discovery won't work. Laravel's dont-discover/auto-discovery logic looks for Illuminate\Support\ServiceProvider; a Symfony Bundle subclass is invisible to it.
  • Config key is namespaced. The bundle's options live under a snake_case root key (e.g. opensoft_epl:). There is no Laravel equivalent — you'll re-declare those keys in config/epl.php and lose the Symfony config-tree validation, so validate manually.
  • In-memory engine state is a trap in queue workers. Long-running queue:work processes keep statement state alive across jobs. Reset or scope the engine per job unless you deliberately want cross-job aggregation — otherwise you get tenant leakage and unbounded memory growth.
  • No profiler, no debug: commands. Symfony's debugging affordances are gone. Add explicit logging around statement compilation and match dispatch, and dump the compiled rule plan in a test.
  • Extension points are Symfony-shaped. Compiler passes and tagged services are the only extension mechanism in the bundle — port them to Laravel container tags and a service provider; there is no other hook.
  • Upgrade path: vendor the services.yml wiring as a one-time reference, pin the underlying library to a known commit, and budget to fork or replace it, because upstream is dormant.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console