Core Laravel Package

Product Decisions This Supports

• Dependency-risk tracking, not roadmap delivery. graham-campbell/core ships zero user-facing behavior. It is an abstract Laravel ServiceProvider plus sugar methods (config merge/publish, view and translation loading, migration/route registration, command and binding helpers). It should appear in planning documents only as a risk line, a maintenance-cost entry, or an input to upgrade sequencing — never as a feature or deliverable.
• Legacy-stack triage with forecast impact. Its presence in a composer.lock is hard evidence of pre-Laravel-5.5 architecture (manual provider registration, no package auto-discovery) pinned to Laravel 5.0–5.8 and PHP 5.5–7.x. That single fact should recalibrate delivery-velocity forecasts, security-review effort, and upgrade scope on that codebase. Treat it as a data point, not an opinion.
• Upgrade sequencing. It forces one of two product choices: (a) fold its removal into a Laravel upgrade you were already scoping — near-free, since the codebase is blocked on modern PHP/Laravel anyway; or (b) freeze that application in a maintenance lane with no new feature investment. A standalone "remove the package" initiative is never worth the review cycle, regression window, and rollback plan it costs.
• Build vs. buy vs. delete. There is no "buy" and no "build" case — only a delete case. The honest options are: retain as-is, replace with a ~30-line in-house trait (only if a concrete subclassing need survives audit), or delete outright. The product goal is to shrink custom surface area, and this package is precisely the kind of custom surface area to shrink.
• Inherited-codebase due diligence. Zero stars, zero dependents, archived under GrahamDeprecated, no issue tracker history, no maintainer, no CVE process. Any path depending on it converts immediately to "we own it." That is a scoping input for acquisitions, vendor handoffs, and inherited repos — and it typically favors inlining over depending.
• Internal package standards. It is a useful reference anti-pattern. The house rule it teaches: new internal packages use native Illuminate\Support\ServiceProvider methods (mergeConfigFrom, loadViewsFrom, loadTranslationsFrom, loadMigrationsFrom, loadRoutesFrom, publishes, commands) plus composer.json extra.laravel.providers. This belongs in engineering guidelines and code-review checklists.
• Effort estimation via a timeboxed spike. The surface is small — an abstract provider and a handful of helpers. Porting one concrete subclass to native APIs (with a boot check: route:list, queue:work --stop-when-empty, schedule:list) converts a vague "legacy risk" into an hours-not-days estimate. That is the concrete PM artifact: a number you can put in a plan instead of a worry.

When to Consider This Package

Consider it — and "consider" here almost always means investigate, then remove — when:

• composer why graham-campbell/core returns a result on a codebase you own and are scoping for upgrade or maintenance. The follow-up question is always "which dependent pulled it in, and is that dependent also abandoned?"
• A dependent package's service provider declares extends AbstractServiceProvider, and you need to understand which protected properties ($config, $views, $lang, $routes, $migrations, $commands, $bindings, $singletons) are actually driving behavior before you port it.
• You are evaluating a repo for acquisition or handoff and need a fast architectural read: this package is a strong signal of pre-auto-discovery design.
• You are writing or revising internal package conventions and want a canonical example of what not to recreate.

Look elsewhere — or rather, do not adopt — when:

• The project targets Laravel 5.5+. Native APIs cover 100% of the package's value. Installing it adds a dependency with no support channel in exchange for nothing.
• The project runs PHP 8.x. Composer refuses at install time; pinning illuminate/* to a 5.x branch does not help. This is a PHP floor problem, not a Laravel version problem.
• You are tempted to fork it to "keep it alive." The code is small enough to inline and small enough to rewrite that a fork is strictly worse than both. You would inherit maintenance, CVE triage, and the false comfort of upstream in exchange for saving a few hundred lines. The two correct endpoints are delete and vendor thirty lines under your own namespace.
• You need a support contract, CVE process, or community answers. There are none. Zero dependents means zero issue-tracker history containing your stack trace. Do not budget "waiting on upstream."
• A dependent relies on the storage-link helper. v5.3.2 exists because v5.3's fix didn't fix it — a demonstrated regression inside a shipped helper. Move that call to php artisan storage:link in the deploy script; provider-time filesystem side effects are hard to test and hard to roll back.

How to Pitch It (Stakeholders)

To executives: This is a small, abandoned utility library that provides no user-facing functionality but is a reliable indicator that the codebase it lives in is built on an end-of-life Laravel and PHP stack. It has no maintainer, no security-response process, and no other consumers — so any bug in it becomes ours permanently. Our recommendation is not to invest in it: we remove it as part of the upgrade we already need to do, or we freeze the application in maintenance. Removal bundled into an upgrade is nearly free; removal as a standalone project costs a review cycle and a regression window for a change users will never see. The one artifact worth producing now is a timeboxed spike — port a single provider, run the test suite and a boot check — which gives us a real effort estimate instead of an open-ended risk.

To engineering: Do not composer require this on anything new. When you encounter it, run composer why first: absent means read-and-move-on; transitive means your ticket is "bump or replace the dependent package"; direct means your ticket is "edit code in our repo." These have different reviewers and different rollback plans — conflating them doubles the estimate. Port the concrete subclass, not the abstract class, using the standard translation table: $config → mergeConfigFrom in register() (not boot() — putting it in boot() regresses startup config and surfaces as "config missing in a service constructor"); $views/$lang/$migrations/$routes → the corresponding load*From calls in boot(); $bindings/$singletons/$aliases → plain container calls in register(); manual config/app.php entries → extra.laravel.providers in composer.json. Grep subclasses for overridden register()/boot() before deleting extends — those are behavior you must reproduce explicitly. Namespace your publish tags (x-config, not config) so vendor:publish --tag=config doesn't fire two packages. Snapshot composer.lock before touching constraints. And write the finding to /docs/legacy/ rather than waiting on an upstream that isn't coming.