Common Laravel Package

Getting Started

swp/common is not a Laravel package — it is a Symfony-oriented shared library extracted from Superdesk Web Publisher via a read-only subtree split. Treat it as a low-level utility/domain library you drop into vendor/, not something you artisan against.

Minimal steps:

1. Verify it will even install. Before writing code, run:

   composer require swp/common --dry-run
   

   The last tagged release is 2018-06-08, so its composer.json constraints (php, symfony/*) are from the PHP 7.1/7.2 era. On a modern Laravel 10/11 app (PHP 8.2+) you will frequently hit constraint conflicts. If the dry run fails, do not force it with --ignore-platform-reqs unless you have read the source and confirmed it is pure PHP with no deprecated semantics.
2. Read the source, not the docs. There is no documentation site for this split. Open vendor/swp/common/src/ and vendor/swp/common/tests/ — the tests are the only reliable usage examples.
3. Check composer.json for the real dependency surface (which Symfony components, whether it pulls in Doctrine, PSR interfaces, etc.). Anything it drags in becomes your problem too.
4. First use case: consume the value objects / utility classes it exposes directly, in isolation — do not wire them into your Eloquent models or container on day one. A scratch script or a single unit test that instantiates a class and asserts output is the safest smoke test.

If your goal is "use this in a Laravel app," first ask whether you actually need it. With 1 star, 0 dependents, and an 8-year-old last release, the honest answer is usually no — port the 20–50 lines you actually need instead.

Implementation Patterns

Because this is a Symfony subtree split, the integration patterns are generic-PHP rather than Laravel-idiomatic. Practical approaches:

Pattern 1 — Direct use of pure value objects / stateless helpers. If the class has no container or framework dependencies, this is the only pattern worth adopting:

// app/Support/SwpBridge.php
namespace App\Support;

use Swp\Common\SomeValueObject; // confirm exact FQCN in vendor/

final class SwpBridge
{
    public static function wrap(string $raw): SomeValueObject
    {
        return new SomeValueObject($raw);
    }
}

Keep a thin adapter layer between your app and the package. That way an abandoned dependency is a one-file swap, not a codebase-wide refactor.

Pattern 2 — Bind interfaces in a service provider. If the package ships interfaces (common Symfony components typically do), register concrete implementations in AppServiceProvider::register() rather than letting new calls scatter. There is no auto-discovery — you must write this yourself.

Pattern 3 — Custom Eloquent casts / accessors for value objects. If SWP ships immutable value objects, they are a natural fit for a Castable:

protected $casts = ['slug' => SwpSlugCast::class];

This is the one place where a Laravel app genuinely benefits — the package gives you domain primitives, Laravel gives you the plumbing.

Pattern 4 — Use it as a reference implementation, not a dependency. Given the license and staleness, the most defensible workflow is: read the source for the approach (how they model X), reimplement internally, and avoid the runtime dependency entirely. No composer constraints, no AGPL surface area, no abandonment risk.

Testing tip: copy the relevant test from vendor/swp/common/tests/ into your own suite before you build on top of it. If those tests fail on your PHP version, stop.

Gotchas and Tips

• AGPL-3.0 is the headline risk. Unlike MIT/Apache, AGPL-3.0 is copyleft and network-triggered. If you ship a SaaS that links this library, the AGPL arguably obliges you to offer the corresponding source to your users. Get legal sign-off before production use — this alone disqualifies it for most commercial Laravel apps.
• Abandoned since 2018. No PHP 8 support, no security patches, no maintenance. Any CVE in a transitive Symfony dependency is yours to fix.
• Read-only subtree split. Do not open issues or PRs against SuperdeskWebPublisher/common — they will be closed. All work happens in the parent superdesk/web-publisher repository. This also means version tags in the split can lag or diverge; pin to a dev-master or explicit commit hash rather than floating.
• It is not Laravel-aware. No ServiceProvider, no Facade, no config/ file, no publishable assets, and no extra.laravel block. composer require gives you nothing but files.
• Expect Symfony leakage. Even "common" components usually type-hint against symfony/* interfaces. Mixing those with Laravel's own contracts produces dependency confusion; keep the boundary strict.
• Debugging abandonment: if a class misbehaves, you cannot expect an upstream fix. The escape hatch is composer.json's repositories + a path fork — commit the vendor directory or a patched fork into your own VCS, and document it loudly for the next developer.
• Extension points are class inheritance only. Without DI-friendly abstractions or events, customization typically means subclassing package classes. That is brittle at version bumps; prefer composition.
• Check for global state / static registries. Older Symfony-era utility libraries often hide singletons. Grep static:: and $GLOBALS in src/ before you rely on any class being testable in parallel.

Bottom line for a Laravel developer: the cost/benefit is poor. The package is dated, AGPL, unmaintained, and framework-aligned to Symfony. Adopt it only for a genuinely small, pure-PHP piece you have audited, wrapped behind an adapter, and cleared legally — otherwise vendor the specific logic you need and move on.