Common Laravel Package

Technical Evaluation

• What this actually is. swp/common is a read-only subtree split of the Common component of Superdesk Web Publisher — Sourcefabric's Symfony-based, multi-tenant publishing platform. It is not a Laravel package: there is no service provider, no facade, no Laravel-shaped configuration, and no Laravel documentation. It appears in a Laravel/PHP scan because it is Composer-installable, not because it fits the stack.
• Architecture fit: low. The component carries publishing-domain primitives (shared entities, value objects, traits, possibly Doctrine mappings) that are "common" within SWP, bound to SWP's bundle conventions and to Symfony's container/event model. Any reuse in a Laravel application would be at the plain-PHP class level and limited to the subset that is genuinely framework-agnostic — which is unverified.
• Integration feasibility: technically yes, operationally no. composer require swp/common will resolve or it won't; either way there is no supported integration path, no usage examples outside the SWP monorepo, and no known consumers (1 star, 0 dependents). The realistic pattern is vendor-and-fork, not depend-and-track.
• Technical risk, ranked.
  1. Licensing — AGPL-3.0. For any network-delivered product this is the dominant risk. Obligations attach to the combined work, not just this package, and the "offer source to network users" trigger is easy to trip accidentally. This alone should gate the decision.
  2. Abandonment. Last release 2018-06-08. No maintainer activity, no issue tracker on the split repo, no security response process.
  3. Compatibility drag. Pinned to PHP 7.x / Symfony 3–4-era constraints; conflicts with modern Laravel (PHP 8.2+, Symfony 6/7 components) are likely both in its own composer.json and in transitive dependencies.
  4. Hidden coupling. Subtree splits frequently drag in sibling SWP packages; "common" may not be standalone.
  5. Zero validation signal. No dependents means no field evidence this code has ever run outside its monorepo.
• Key questions for the team. Is the monorepo still publishing this split, i.e. is the tag we would pin reproducible? Which transitive SWP packages does it pull? Can we name the specific classes we want — and are they framework-free? Who owns the AGPL decision, and has Legal accepted the network-copyleft exposure? What is our PHP/Symfony floor? Is there a maintained library that already does this?

Integration Approach

• Stack fit. Poor. SWP targets Symfony; a Laravel app shares only PHP and Composer with it. Treat the package as a source of domain inspiration, not as a runtime dependency.
• Migration path, in order of preference.
  1. Do not install. Read the source, document the domain model, reimplement the small pieces we actually need in our own namespace. This is the default.
  2. Extract, don't depend. If one or two classes are worth keeping, copy them into our codebase with attribution and a provenance note — after Legal confirms AGPL compatibility and that we are not copying protectable expression.
  3. Depend only as a last resort. Fork to an internal VCS, pin an exact tag/commit, and isolate behind our own adapter interface so removal is a one-file change.
• Compatibility work if we do depend. Audit its composer.json constraints, run composer why-not against our PHP and Laravel versions, and expect to add replace/conflict entries or a polyfill shim. Budget for a lockfile-level conflict-resolution pass, not a five-minute install.
• Sequencing. (a) License review as a hard gate before any code is written; (b) 1–2 day spike installing it in a throwaway branch to measure actual conflict surface; (c) build-vs-borrow decision; (d) if borrowing, adapter plus conformance tests first, wiring second; (e) diarise a replacement review at six months, given the abandonment profile.

Operational Impact

• Maintenance. We would own it outright. The split is read-only, so fixes must go through the SWP monorepo — whose activity we cannot rely on — or live permanently in our fork. Every PHP and Laravel upgrade becomes our problem, not a vendor's.
• Support. None. No maintainer, no security advisories, no CVE feed, no community to escalate to. Incident response reduces to "read the code at 2am."
• Scaling. The package is a library, not a service, so horizontal scaling is a function of our application rather than of this code. The real scaling constraint is team scaling: one engineer understands the fork and the knowledge transfer is undocumented.
• Failure modes for the risk register. Silent transitive dependency drift; PHP-version breakage on upgrade; license contamination discovered late — the worst case, costing rework plus disclosure; a vulnerability with no patch path; fork divergence that forecloses any future upstream merge.
• Ramp-up. Cheap to read, expensive to own. Roughly half a day for a senior PHP engineer to assess the component's surface, 1–2 days to spike an install, and 1–3 days of ongoing tax per upgrade cycle if adopted. Onboarding a second engineer onto a private fork is the hidden cost that rarely makes it into the estimate.
• Recommendation. Reject as a dependency; permit as a design reference only. Revisit solely if SWP revives upstream and Legal clears AGPL for our distribution model — neither of which is true today.