Rule Laravel Package

Technical Evaluation

Architecture fit. swp/rule is not a Laravel package. It is a read-only subtree split of a single component from Superdesk Web Publisher (SWP), a Symfony-based content publishing platform built by Sourcefabric. The component exposes rule/evaluation abstractions (conditions, operators, rule sets) used to drive publishing workflows — publish/hold content based on tags, authors, dates, or metadata. It is architected around Symfony service definitions, PSR abstractions, and sibling swp/* components, not around Laravel's container, facades, or Eloquent. Adopting it into a Laravel codebase means importing a slice of a foreign CMS domain model rather than a self-contained library.

Integration feasibility. Low. The "READ-ONLY subtree split" designation is the decisive signal: the repository is a mechanically generated mirror of a monorepo path, not an independently maintained package. Commit history, issues, and PRs are not tracked here, so there is no upstream triage path through this repo. The NOASSERTION license means the actual terms must be read from the Superdesk Web Publisher root repository (historically AGPL-3.0), which carries copyleft implications for a commercial Laravel product. Realistic integration requires either (a) vendoring and rewriting the Symfony-coupled internals, or (b) reimplementing the rule semantics natively — at which point the package contributes design inspiration rather than code.

Technical risk. High across every axis:

• Staleness. Last release June 2018. Roughly seven years without a commit on the split. PHP 7.2-era code will likely emit deprecations or fatal errors on PHP 8.2+, and transitive Symfony/Doctrine constraints from 2018 will conflict with any modern Laravel 10/11 lockfile.
• Abandonment. Zero stars, zero dependents, zero downstream consumers to validate against. No maintainer signal, no CVE response capability.
• Coupling. Expect hard dependencies on swp/common, swp/content-bundle, Doctrine entities, and Symfony event dispatching that drag a large transitive footprint into a Laravel app.
• License ambiguity. NOASSERTION is a compliance blocker that must be resolved by legal before any code enters the repository, not after.

Key questions for the requesting team.

1. What problem is being solved — content workflow automation, generic business rules, or feature flags? A modern rule engine (e.g., symfony/expression-language, nikic/php-parser-based DSLs, or a maintained rules library) likely covers it more safely.
2. Is the goal to reuse SWP semantics (specific publishing-domain rules) or simply to evaluate conditions? Only the former justifies looking at this repo at all.
3. Has legal confirmed the effective license from the SWP monorepo, and are AGPL obligations acceptable?
4. Who owns the fork? If we vendor this, we own it forever with no upstream.
5. What is the supported PHP/Laravel version matrix for the target application?

Recommendation. Do not integrate as a dependency. Treat it as a reference implementation — mine the rule/condition abstractions and rewrite them against Laravel contracts if the domain semantics are genuinely needed.

Integration Approach

Stack fit. Poor as a drop-in, workable as a design reference. SWP is Symfony-first and content-domain-specific; Laravel applications typically express equivalent logic through policies, gates, events/listeners, queues, and form requests. The conceptual overlap is real (conditions → evaluators, rule sets → pipelines), the code overlap is negligible.

Migration path (if pursued). A staged, fork-first approach is the only defensible one:

1. License clearance. Resolve NOASSERTION against the SWP root repo and record the determination in the architecture decision record before any code is copied.
2. Vendor, don't require. Composer-install is not viable given the 2018 constraint graph. Copy the source into an internal namespace (App\Domain\Rules) and sever Symfony/Doctrine coupling.
3. Port the abstractions, not the wiring. Reimplement rule, condition, and evaluator interfaces against Laravel contracts — container bindings, config, and a persistence layer on Eloquent rather than Doctrine.
4. Replace the evaluation engine. Where SWP dispatches Symfony events and leans on its content model, substitute Laravel events and application-specific DTOs.
5. Golden tests. Extract the rule semantics into a behavior test suite so the port is verifiable against documented SWP behavior rather than assumed parity.

Compatibility. Assume PHP ≤7.4 and Symfony 3.x/4.x transitive constraints; a Laravel 10/11 target requires a full modernisation pass (typed properties, constructor promotion, PSR-11 alignment, removal of deprecated helpers). Budget for that rewrite explicitly — it is the dominant cost, not the integration glue.

Sequencing. Run this as a spike, not a sprint commitment: two to three days to (a) confirm license, (b) inventory the component's transitive swp/* and Symfony dependencies, (c) prototype one rule end-to-end in Laravel. Gate any further investment on the spike demonstrating that reusing SWP semantics is materially cheaper than building a small native rule engine. Given the 2018 codebase, the spike will most likely conclude "build, don't port."

Operational Impact

Maintenance. Effectively unmaintained upstream and, if forked, wholly owned internally. There is no upgrade path, no patch stream, and no maintainer to escalate to. Every future PHP or Laravel major version becomes an internal migration project for code nobody on the team wrote.

Support. Zero community: no stars, no dependents, no issue traffic on the split, and a monorepo that has itself been quiet. Internal engineers become the sole support channel, including for security issues in abandoned transitive dependencies. This is the single largest operational liability.

Scaling. The component is a rule evaluator, not a scaling bottleneck in itself; cost scales with rule count and evaluation frequency. In a high-volume Laravel app, evaluation belongs in queued jobs with cached compiled rule sets, not synchronous request paths. Nothing about SWP's implementation confers scaling advantages — that design work is on us either way.

Failure modes.

• Silent semantic drift during porting — rules that appear to work but diverge on edge cases (null metadata, timezone-sensitive date conditions, operator precedence), producing wrong publish/hold decisions.
• Dependency archaeology — a transitive 2018 constraint blocks a routine composer update months later, forcing an unplanned migration.
• License exposure — copyleft obligations discovered post-deployment, requiring remediation under time pressure.
• Bus factor of one — the engineer who performed the port leaves, and the fork becomes opaque tribal knowledge.

Ramp-up. Steep and unproductive for new hires: they must learn a foreign CMS's domain model to maintain code with no documentation, no upstream, and a seven-year gap from current practice. Contrast this with a native, well-documented rule implementation that onboards in days.

Bottom line. For a TPM, this package scores as a reference artifact, not a dependency. The opportunity score (17.34) and the zero-star/zero-dependent profile align: there is no ecosystem to lean on. Recommend capturing the rule abstractions as design input, resolving the license question for the record, and building a small Laravel-native evaluator. Revisit only if the SWP monorepo is revived with an active maintainer and a clarified license.