paxha/artisan-view
paxha/artisan-view adds a lightweight web interface for Laravel Artisan commands, letting you browse available commands, inspect their signatures and descriptions, and run them directly from the browser—handy for local development, debugging, and quick admin tasks.
Install the package with Composer and let Laravel's package auto-discovery register the service provider (on older Laravel versions you may need to add Paxha\ArtisanView\ArtisanViewServiceProvider to config/app.php manually):
composer require paxha/artisan-view
The first thing to check after install is the command signature — run php artisan list and look under the make namespace for a view-related command (typically make:view). Read the command's --help output to confirm which options your installed version exposes, because this package is small and its flag set varies between tags:
php artisan make:view --help
Your first productive use case is scaffolding a Blade file you'd otherwise create by hand. Instead of touching resources/views/posts/index.blade.php in your editor, run:
php artisan make:view posts.index
That gives you a real file at the correct path, which you can immediately wire into a route or controller. From there the natural next step is to pass layout options so the generated stub isn't an empty file — see the patterns below.
Dot notation maps to directories. Names mirror Laravel's view resolution: make:view admin.users.edit creates resources/views/admin/users/edit.blade.php. Use this to scaffold whole resource trees in one pass:
php artisan make:view posts.index
php artisan make:view posts.show
php artisan make:view posts.create
php artisan make:view posts.edit
Layout inheritance on generation. The most useful day-to-day pattern is generating a view that already extends your master layout and injects a section, rather than an empty stub. Typical flag shapes (verify against --help for your version) look like:
php artisan make:view posts.index --extends=layouts.app --section=content
This produces something like @extends('layouts.app') with a @section('content') ... @endsection block, saving you the boilerplate every time. Adopt this as your team's default invocation so generated views are immediately renderable in your layout.
Pair with resource controllers. When you run make:controller PostController --resource, the controller returns view('posts.index'), view('posts.show'), etc. Generate the matching views in the same sitting so the resource route set works end-to-end before you write any markup. This is the strongest workflow argument for the package: it keeps controller and view scaffolding in lockstep.
Force overwrite deliberately. If your version supports a --force flag, use it only when regenerating throwaway stubs. For anything with real markup committed, treat an existing view as sacred and edit in place — regenerating over hand-written Blade is a silent data-loss hazard.
Team convention via a wrapper. Because the flag names are easy to forget and vary by release, encapsulate your standard invocation in a Composer script or a small shell alias (e.g. make:view-stub) so every developer scaffolds views identically and nobody has to reread the README.
Version drift is the real risk. This repository has essentially no traction (zero stars, zero dependents in the dataset), which means it is unlikely to be actively maintained against current Laravel releases. Before adopting, confirm the installed tag supports your Laravel version's service-provider and command-registration APIs. If auto-discovery fails silently, the command simply won't appear — check php artisan list before assuming a bug in your app.
Confirm the actual command name. Community view-scaffolding packages have shipped under a few signatures (make:view, view:make, artisan-view:make). Run php artisan list | grep view after install rather than trusting a tutorial; a "command not found" here is almost always a naming mismatch, not a broken install.
Path resolution follows config. If the package publishes a config file, the target view path may be configurable. Run php artisan vendor:publish and inspect it. Generating into the wrong directory is the most common confusion — the fix is usually re-publishing or clearing config:cache after editing.
Clear caches when the command misbehaves. If the command disappears after a deploy or behaves inconsistently, run php artisan config:clear && php artisan cache:clear. Package discovery is cached in bootstrap/cache/packages.php; a stale cache is a frequent culprit for "the command worked yesterday."
Respect PSR-4 and view caching during debugging. After generating or overwriting a view, if changes don't appear, run php artisan view:clear — compiled Blade lives in storage/framework/views and stale compilations can mask what was actually generated.
Extension points are thin. Don't expect plugin hooks or stub customization à la make:controller --stub. The pragmatic extension path is to fork the package's stub or, better, wrap it in your own artisan command that calls the underlying generator and applies your house style. Given the project's low activity, plan for the possibility that you outgrow it and need to maintain a fork — keep your invocation logic isolated so swapping it out is a one-file change.
How can I help you explore Laravel packages today?