Common Laravel Package

Getting Started

xrow/common is a small, MIT-licensed utility package published by xrow GmbH (an eZ Publish / Ibexa agency) and last tagged in May 2015. Treat it as source material to read and cherry-pick from, not as a dependency to require in a modern project.

Minimal steps to get oriented:

git clone https://github.com/xrowgmbh/common && cd common
cat composer.json          # autoload style, PHP constraint, deps — read this first
find . -maxdepth 2 -type d # discover the namespaces / bundle layout
git log --oneline --decorate -20
git tag                    # confirm 2015 is the real ceiling

Where to look first, in order:

1. composer.json — the require block tells you whether it pulls in ezsystems/*, symfony/*, or nothing at all. That single fact determines whether it is a general-purpose helper library or an eZ Publish-specific bundle, and dictates everything else.
2. The autoload section — psr-0 vs psr-4 vs classmap tells you how much work a modern install will be.
3. The src/ / lib/ tree — scan class names for what is actually reusable (string/array helpers, validators, format converters) versus what is glue for a specific eZ site.
4. README / any Resources/config — for a Symfony bundle this is where service wiring and extension points live.

First use case, realistically: open the tree, find the two or three genuinely generic helpers you need, and copy them into your own app/Support/ or src/Util/ namespace with a header comment pointing at the source commit and MIT license. That gets you value in ten minutes without inheriting a decade-old dependency graph.

If you insist on installing it, do it in a throwaway project first:

composer require xrow/common --no-scripts
composer why-not xrow/common   # see what blocks resolution on your PHP/Symfony

Implementation Patterns

Vendor-and-fork (recommended default). Because it is MIT and effectively unmaintained, the sustainable pattern is to own the code:

{
  "repositories": [
    { "type": "vcs", "url": "https://github.com/yourorg/common-fork" }
  ],
  "require": { "xrow/common": "dev-master" }
}

Fork, bump the PHP constraint, convert psr-0 to psr-4, add a ^8.1 platform requirement, tag 1.0.0, and now you have a normal dependency you can patch. This is almost always cheaper than fighting Composer resolution against 2015-era constraints.

Wrap, don't scatter. If you do consume it as-is, put it behind one seam so a future removal is a one-file change:

namespace App\Support;

final class Slugger
{
    public static function make(string $value): string
    {
        return \xrow\Common\...::slugify($value); // the one call site
    }
}

Then a grep for the namespace yields exactly the surface you depend on, and you can replace each method with a symfony/string or illuminate/support equivalent later.

Service container registration (if it ships a bundle). For a Symfony/eZ bundle, register it explicitly in config/bundles.php (or AppKernel) and keep its service definitions in your own services.yaml rather than relying on the bundle's Resources/config — you want the wiring visible in your app, especially for a package nobody is testing.

Prefer injection over statics. Old utility libraries are usually static-method heavy. Even so, inject via constructor and type-hint the class; do not call statics from deep inside domain code, or you lose testability and the ability to swap the implementation when you retire the package.

Selective re-implementation. For anything under ~40 lines — a slugifier, a byte formatter, a recursive array merge — reimplement it against symfony/string or Laravel's Str/Arr instead of importing. You will write it faster than you will debug the 2015 version on PHP 8, and you avoid the license-header bookkeeping.

If it targets the eZ Publish legacy stack, isolate it in a legacy bridge/legacy kernel adapter and never let its types leak into your controllers. The legacy APIs it likely calls (eZContentObject, eZTemplate) are gone from Ibexa 4+, so the code is only useful inside a legacy-bridge context anyway.

Gotchas and Tips

The dependency itself is the pitfall. Zero stars, zero dependents, last release 2015-05-07. There is no bus factor to speak of and no one to file issues with. Any bug you hit, you own — permanently. Budget for that before composer require.

PHP version constraints will likely block install. A 2015 package typically declares php: >=5.3 or ~5.4 and may pin symfony/*: ~2.x. On PHP 8.1+ you will either get a hard resolution failure or — worse — a successful install that then emits E_DEPRECATED and E_WARNING noise. Always test in a scratch environment first, never on the branch you plan to ship.

Autoload is probably psr-0. If so, class names map to underscore/directory conventions and the vendor path gets long. When forking, do the psr-0 → psr-4 conversion immediately, run composer dump-autoload -o, and verify with composer dump-autoload --strict-psr (Composer 2.6+).

Static state and global functions. Utility packages from this era often rely on statics, define()d constants, or global helper functions. Those collide silently under parallel test runners and are invisible to grep for the namespace. Search for function at file scope and static $ before you trust it in a long-running worker.

No tests means no safety net. Do not assume behavior is correct or documented — read every method you call, end to end. Add characterisation tests around the specific methods you use; those tests are what let you substitute a modern implementation later with confidence.

License hygiene is the one thing that is easy here. MIT means you can copy, modify, and ship commercially. Keep the copyright notice and the license text in whatever you vendor, and note the upstream commit hash in the file header so future-you can diff.

Debugging a weird failure usually traces back to a hidden dependency on an eZ Publish kernel, a Symfony 2 service, or a global constant. Run composer why xrow/common, then instrument with a stack trace from the failing call — do not try to reason about it from the README alone.

Extension points to look for are the ones you can use without forking: constructor-injected config, an interface you can implement, or a Symfony service you can override via a compiler pass. If none exist — common for a package this size — the extension point is your fork. Treat "does it have a seam?" as the go/no-go question.

Verdict for day-to-day use: do not add this to a production composer.json. Read it once, lift the handful of utilities that are actually generic, reimplement the rest on symfony/string/Str, and move on. The only scenario where a real dependency makes sense is inside an existing legacy eZ Publish 5 codebase that already pins the exact same 2015-era constraint set.