Laravel Common Laravel Package

Technical Evaluation

Architecture fit. reliqarts/laravel-common is a "base/common" package: the class of library that supplies base models, base controllers, shared traits, and global helper functions. Architecturally this sits at the bottom of the dependency graph and becomes the superclass of everything above it. That is the single most consequential property of the package and it is a poor fit for any application that already has opinionated conventions (App\Models\Model, a service layer, domain-specific traits). Where an existing codebase already defines its own base abstractions, this package is either a no-op duplicate or a forced refactor of foundational classes — the highest-churn, lowest-reward kind of refactor. Fit is credible only if the team has deliberately standardized on Reliq Arts conventions, which is unlikely outside the author's own projects.

Integration feasibility. Mechanically trivial: Composer package, MIT licensed, presumably PSR-4 autoloaded with optional Laravel auto-discovery. Installation is minutes. The real feasibility question is version compatibility — packages of this profile frequently pin illuminate/support to an older major and go quiet. That must be confirmed against composer.json before anything else.

Technical risk. High, and almost entirely supply-side rather than code-quality:

• Bus factor 1. No dependents and 2 stars means no ecosystem pressure to keep it current with Laravel majors.
• Foundational lock-in. Base classes are the hardest artifact to remove later; extraction cost compounds with every subclass written.
• Global surface area. Helper functions and service-provider registrations touch global namespace and container state; collisions with Laravel's own helpers or a future dependency are possible and fail at runtime, not compile time.
• No external validation. Zero dependents means zero independent production evidence.

Key questions.

1. What is actually in src/ — how many classes, and how much duplicates Laravel-native primitives?
2. What are the illuminate/* and PHP version constraints, and what was the last commit/release date?
3. Is there a test suite, and at what coverage / static-analysis level?
4. Does the service provider register macros, helpers, config, or bindings globally?
5. Are the base classes abstract and thin, or do they carry concrete behavior (scopes, magic accessors) that subclasses silently inherit?
6. Can the handful of genuinely useful traits be copied in-tree under MIT attribution instead of taking the dependency?

Integration Approach

Stack fit. Laravel-only, and only for teams without established base abstractions. A greenfield project could theoretically adopt it on day one; a mature codebase should not.

Migration path. Recommended posture: reference, do not depend. Audit the source and cherry-pick individual traits/helpers into app/Support/ with MIT attribution and a provenance note. If the dependency is genuinely required, fork it into an internal org/laravel-common package so versioning, CI, and security patching are under your control — this converts an unmaintained external dependency into an owned internal one at low cost. If consuming it directly, wrap usage behind your own base classes so the vendor can be swapped without touching leaf classes.

Compatibility. Verify composer.json constraints against the target Laravel and PHP versions, run the suite (if any) against a scratch app, and check for deprecated Laravel APIs. Also confirm PSR-4 namespace collisions and whether the package ships a config file that must be published.

Sequencing.

1. Source audit: composer.json, src/, tests/, git log, release tags.
2. Install into a disposable Laravel app; exercise every public class and helper.
3. Class-by-class value assessment — most will likely be "copy this one trait."
4. Decide: copy-in (default), internal fork (if broad usage), or direct dependency (only with a pinned exact version and commit hash).
5. Add a CI job and a divergence README if forked; otherwise document the attribution.

Operational Impact

Maintenance. Assume the upstream will not track Laravel majors. Effective ownership transfers to your team on day one. Budget a recurring review per Laravel upgrade cycle plus a plan for the eventual removal or fork.

Support. Community support is effectively nil — no issue triage capacity to rely on. Internal expertise is the only support channel; document it in the ADR.

Scaling. Runtime cost is negligible. The scaling risk is organizational: every new service inherits the base classes, so any defect or awkward abstraction in the base multiplies across the codebase and raises the cost of later correction.

Failure modes.

• Laravel major upgrade blocked by stale constraints.
• Global helper name collision introduced by a future dependency — runtime fatal, discovered late.
• Patch-level change in a base class silently altering subclass behavior.
• Inherited magic methods (__get, scopes, casts) producing surprising behavior in domain models.
• Security fix never shipped upstream; you absorb the exposure.
• Abandonment/archival with no migration note.

Ramp-up. Reading the package is a few hours. The hidden cost is conceptual: new engineers must learn non-standard base classes and an ambiguous "where does shared logic live" convention that competes with Laravel's own idioms. That onboarding tax persists for the life of the dependency.

TPM verdict. Low strategic value, high coupling, unvalidated supply chain. Recommend declining as a dependency; treat as a source of MIT-licensed snippets at most. Revisit only if the package demonstrates recent releases, real test coverage, and independent adopters.