Weave Code
Common Laravel Package
swp/common
A shared common library for Laravel and PHP projects, bundling reusable helpers, traits, and utilities that keep your codebase consistent and reduce duplication across applications and packages.
[READ-ONLY] Subtree split of the Superdesk Web Publisher Common Component
Frequently asked questions about Common
- Is swp/common a Laravel package?
- No. Despite being described as Laravel-friendly, swp/common is a read-only subtree split of the Common component from Superdesk Web Publisher, a Symfony-based publishing platform. It ships no service provider, facade, or Laravel-style configuration, so nothing auto-registers in a Laravel app. Any usable pieces are plain PHP classes you would have to wire up yourself.
- How do I install swp/common with Composer?
- You can run composer require swp/common, but expect the resolver to fight your PHP 8.x and modern Symfony or Laravel constraints. The package is a read-only split with no supported integration path and no usage examples outside its monorepo. Audit its composer.json first and run composer why-not swp/common before you touch your lockfile.
- Which PHP and Laravel versions does swp/common support?
- The last release dates to June 2018 and is pinned to PHP 7.x with Symfony 3-4-era constraints. There is no declared Laravel version support at all, and installing it alongside Laravel 10 or 11 on PHP 8.2+ will likely need replace or conflict entries. Treat any compatibility as something you must verify and maintain yourself.
- What license is swp/common and can I use it in a closed-source SaaS?
- It is licensed AGPL-3.0, which is network copyleft: if you run a modified version as part of a network-delivered service, you may be obliged to offer the corresponding source to your users. That obligation attaches to the combined work, not just this package, which is a serious concern for proprietary products. Get a legal review as a hard gate before writing any integration code.
- Is swp/common still maintained?
- No. The last tagged release was 2018-06-08, the split repository is read-only, and there is no issue tracker or security response process. With one star and zero dependents, there is no evidence the code has ever run outside the SWP monorepo. If you adopt it, you own it outright, including fixes that would otherwise go upstream.
- What classes and traits does swp/common actually contain?
- It carries publishing-domain primitives that are common within Superdesk Web Publisher: shared entities, value objects, traits, and possibly Doctrine mappings. Most of that is bound to SWP bundle conventions and Symfony's container and event model rather than being general-purpose helpers. Only a subset, if any, is genuinely framework-agnostic, and that subset is unverified.
- Will swp/common cause dependency conflicts in a modern Laravel app?
- Very likely. Its PHP 7.x and Symfony 3-4 constraints clash with PHP 8.2+ and Symfony 6/7 components, and subtree splits often drag in sibling SWP packages you did not ask for. Budget for a real lockfile conflict-resolution pass rather than a five-minute install. If you proceed anyway, isolate it behind your own adapter interface so removal is a one-file change.
- What are good alternatives to swp/common for shared traits and helper functions?
- For generic helpers, Laravel's own Illuminate\Support utilities plus small internal shims usually cover what teams actually need. For shared traits and value objects, a tiny internal package in your own namespace is often cheaper and safer than adopting an abandoned dependency. Start by listing the specific classes you want, since that list is typically short.
- How should I test swp/common before using it in production?
- Run a one-to-two day spike in a throwaway branch: install it, then use composer why-not against your PHP and Laravel versions to measure the real conflict surface. Write conformance tests around whatever behavior you depend on, because there is no upstream test signal and no dependent usage to learn from. Do this before any production wiring, not after.
- Can I fork swp/common or copy classes into my own project?
- Copying individual classes with attribution and a provenance note is the lower-risk route, but only after legal confirms AGPL compatibility and that you are not reproducing protectable expression. If you need the package itself, fork it to an internal VCS, pin an exact tag or commit, and wrap it behind an adapter. Also diarise a replacement review at six months given the abandonment profile.
Weaver
How can I help you explore Laravel packages today?