Laravel App Laravel Package

Technical Evaluation

Architecture fit. dragon-code/laravel-app is a single-purpose artisan-command shim: a service provider that re-registers app:name, the namespace/config-rewriting command that Laravel deprecated in 8.x and removed in 9.x. It has no request-path footprint — no middleware, no facade, no config merge, no migrations. Structurally it fits any Laravel app via package auto-discovery, but it is developer tooling, not application architecture. It belongs in require-dev at most; shipping it in production require would be a category error.

Integration feasibility. composer require dragon-code/laravel-app and it works — on the versions it was built for. The package was last released 2022-02-14, which places its verified target at Laravel 9.x. The command's core mechanism is string substitution over config/app.php plus PSR-4 namespace edits, and that assumed file layout is the pre-11 slim skeleton. Feasibility is therefore high-but-bounded: trivial to install, unverified beyond Laravel 9.

Technical risk.

• Archived upstream. No security advisories, no CVE response, no Laravel 10/11 compatibility patches. Any breakage is ours to fix.
• Destructive operation. app:name rewrites source namespaces in place. Historically this was removed partly because it produced half-applied renames (namespace changed, autoload map stale, composer dump-autoload failing) that were painful to reverse. This is the dominant risk, not the package itself.
• Zero dependents, 28 stars. No evidence of production hardening. Treat as untested code.
• Command collisions. If another package or an in-house command registers app:name, last-registered wins silently.
• Supply chain is low-surface (small, MIT, verifiable in ~100 LOC) but also unowned.

Key questions.

1. Do we still invoke app:name anywhere — CI scripts, scaffolding docs, onboarding runbooks, or a template repo?
2. If yes, is the requirement actually "rename the namespace" or merely "set the app name"? The latter is APP_NAME in .env and needs no package.
3. Which Laravel versions are in our support matrix today, and does the command's file-patching logic survive the 11.x skeleton?
4. Is a one-time ~30-line internal artisan command cheaper than owning a fork of an archived dependency?
5. Who is accountable for this dependency if it is adopted — and what is the removal date?

Assessment. The opportunity: 8.88 score is the interesting signal: the gap is real (teams migrating 8→9 with app:name in their scripts hit a wall), but the artifact is weak and abandoned. Leverage it as a documented stopgap with a scheduled sunset, or replicate its behavior in-house. Do not let it become a permanent dependency.

Integration Approach

Stack fit. Correct only for Laravel 9.x-era applications with an active 8→9 migration. On Laravel 10 it is plausible but unproven; on Laravel 11 the slim skeleton (no default app/Http/Kernel.php, relocated config publishing, changed autoload expectations) makes silent misbehavior likely. Scope approval to "Laravel 9 migration window, require-dev only."

Migration path. Recommended sequence, cheapest first:

1. Retire the need. Replace php artisan app:name Foo in docs and scripts with APP_NAME=Foo in .env plus a documented find/replace for the App\ namespace. This satisfies the majority of real use cases and eliminates the dependency outright.
2. If the rename must stay automated, write an internal make:rename-app command rather than adopting the package. It is a bounded piece of work: rename the app/ namespace directory structure, patch composer.json autoload.psr-4, run composer dump-autoload, and refuse to run on a dirty working tree.
3. Only if (2) is deprioritized, adopt dragon-code/laravel-app behind a require-dev constraint pinned to ^9.0, with a written sunset date.

Compatibility. Verify empirically before any adoption decision: install on a scratch branch, run the command against a throwaway app on each Laravel version in the matrix, and git diff the result. Treat any Laravel 11 result as failing until proven otherwise. Add a CI job that asserts composer validate and a clean dump-autoload after the command runs.

Sequencing.

• Week 1: inventory every reference to app:name across repos, CI configs, docs, and onboarding material. This determines whether the package is needed at all.
• Week 2: decision gate — retire, replace internally, or bridge with the package.
• Week 3: if bridging, land it as require-dev with a pinned constraint, a smoke test, and a linked sunset ticket.
• Week 4+: execute sunset. Removal is a two-line change (composer remove, delete the runbook reference), so the exit cost is near zero — make sure the sunset ticket exists before the dependency lands.

Operational Impact

Maintenance. Archived means the maintenance burden transfers to us in full. The good news is the code is small enough that forking it into packages/ under our own namespace is a sub-day task for one engineer. Budget that fork rather than assuming upstream will ever move.

Support. No upstream maintainer response, no issue triage, no patches. Internal support means an engineer reading the service provider — which is feasible given its size. The larger support cost is organizational: engineers will discover an archived package in composer.json and lose confidence in the toolchain. Document the rationale and the sunset date in the repo, not just in a ticket.

Scaling. Effectively irrelevant. The package never executes in the request lifecycle, so it has no bearing on throughput, latency, or horizontal scaling. Its invocation frequency is "once per new application scaffold" — single-digit executions per year. Optimize nothing here.

Failure modes. Ranked by impact:

• Partial rename — namespace updated but composer.json PSR-4 mapping or autoload cache stale, producing class-not-found errors at runtime. Highest severity; recoverable only via git checkout or manual repair.
• Over-broad substitution — pattern matching on App as a substring rather than a namespace segment, corrupting unrelated strings.
• Silent no-op on newer skeletons — the command reports success while patching a file path that no longer exists, leaving the developer with false confidence. This is the most dangerous mode because it is invisible until deploy.
• Command collision — another provider registers app:name and wins.
• Mitigation for all four: run only on a clean working tree, mandate a git diff review of the command's output, and add the post-run dump-autoload assertion to CI.

Ramp-up. Near zero for engineers — roughly 15 minutes to read the provider, and the command's UX matches what senior engineers remember from Laravel 8. The ramp-up risk is not learning cost; it is that nobody on the team will know the package is archived, unmaintained, and unverified beyond Laravel 9 unless the decision record says so explicitly.

Bottom line. Treat this as a 60–90 day bridge with a named owner and a hard sunset, and only if the app:name inventory shows real usage. Absent that evidence, the correct TPM move is to decline adoption, fold the behavior into an in-house command, and capture the migration guidance as documentation — which is the durable version of what this package was trying to provide.