- What does dragon-code/laravel-app actually do?
- It is a small Laravel service provider that re-registers the app:name Artisan command, which Laravel deprecated in 8.x and removed in 9.x. The command rewrites config/app.php values and PSR-4 namespaces to rename an application. It is developer tooling with no request-path footprint: no middleware, facade, config merge, or migrations.
- Which Laravel versions does dragon-code/laravel-app support?
- Its last release was 2022-02-14, which places its verified target at Laravel 9.x. It is plausible but unproven on Laravel 10, and Laravel 11's slim skeleton makes silent misbehavior likely. Test it empirically on each Laravel version in your support matrix before adopting it.
- Is dragon-code/laravel-app still maintained?
- No, the project is archived upstream. There are no security advisories, no CVE response, and no compatibility patches for Laravel 10 or 11. Any breakage becomes your responsibility to fix.
- How do I install dragon-code/laravel-app?
- You install it with composer require --dev dragon-code/laravel-app, and package auto-discovery registers the service provider. If you adopt it, pin the constraint to ^9.0 and keep it in require-dev. Do not add it to production require.
- Does dragon-code/laravel-app work on Laravel 11?
- It is not verified for Laravel 11. The Laravel 11 slim skeleton lacks the default app/Http/Kernel.php, relocates config publishing, and changes autoload expectations that the command's file-patching logic assumes. Silent misbehavior is likely, so do not rely on it there without testing and reviewing the resulting git diff.
- Is the app:name command safe to run?
- It performs destructive in-place edits to source namespaces and config/app.php. Historically it produced half-applied renames, such as a changed namespace with a stale autoload map and failing composer dump-autoload, that were painful to reverse. Run it only on a clean working tree and review the diff before committing.
- Do I need dragon-code/laravel-app just to change my application name?
- No. Setting APP_NAME in .env and updating config/app.php satisfies the majority of real use cases without any package. The package only matters if you specifically need automated namespace renaming.
- Should dragon-code/laravel-app be in require or require-dev?
- It belongs in require-dev at most. It is an Artisan-command shim with no runtime request footprint, so shipping it in production require would be a category error. Scope any approval to a Laravel 9 migration window with a written sunset date.
- What are alternatives to dragon-code/laravel-app?
- Write a small internal make:rename-app command: rename the app/ namespace structure, patch composer.json autoload.psr-4, run composer dump-autoload, and refuse to run on a dirty working tree. A documented find/replace for the App\ namespace is often enough. That avoids owning a fork of an archived dependency.
- Can dragon-code/laravel-app conflict with other Artisan commands?
- Yes. If another package or an in-house command registers app:name, the last registration wins silently, so behavior depends on load order. The package has zero dependents, 28 stars, and no evidence of production hardening, so treat it as untested code before relying on it.