Laravel Web Tinker Laravel Package

Getting Started

luminarix/laravel-web-tinker exposes an in-browser PHP REPL (a "web Tinker") inside your Laravel app, so you can run arbitrary PHP against your application's runtime without SSH or php artisan tinker. As of v1.1.0 it also renders a warning badge when the environment is production.

Minimal setup:

composer require luminarix/laravel-web-tinker --dev

Then publish the config if you need to tune it:

php artisan vendor:publish --tag="web-tinker-config"

Where to look first:

1. config/web-tinker.php — controls the route path (typically /web-tinker), middleware stack, and enabled-environment gates.
2. The package's src/ directory — the route registration and controller are small; skim them to understand exactly what is being exposed.
3. routes/web.php — confirm the package route is registered where you expect it (usually under web middleware, and importantly not behind auth by default).

First use case: open the configured route in a browser on local and run something like User::latest()->first() or Cache::get('key') to confirm the REPL executes in your app's context. In v1.1.0, if you flip APP_ENV to production you will see a warning badge in the UI — verify this renders before you decide on your guard strategy.

Implementation Patterns

Keep it strictly local/dev-only. This is a remote code execution surface by design. The sane pattern is:

// config/web-tinker.php (typical)
'enabled' => env('APP_ENV') === 'local',

and gate the route behind auth + a specific ability if you must expose it on a shared staging box. The new production warning badge (v1.1.0) is a visibility aid, not a security boundary — treat it as a reminder, not a control.

Wrap it in a debugging workflow. Common patterns:

• Use web-tinker to dump ad-hoc queries, inspect container bindings (app()->make(Foo::class)), or test a queue payload shape.
• Pair it with dd()/dump() output in the same panel to iterate on a stubborn bug without editing and reloading.
• Use it to prototype an Eloquent query before committing it to a controller or a test.

Session/state-aware exploration. Because the REPL runs inside the app, you can inspect the authenticated user, session, and request context directly — far more useful than CLI tinker for debugging auth and middleware problems.

Environment gating in CI. Add a check (Larastan, a Pest arch test, or a simple config assertion) that the package is only in require-dev and that the route is disabled outside local. This prevents a production deploy of a live REPL.

Feature-flagging per developer. If multiple devs want it on their local installs without polluting default config, prefer an env var (WEB_TINKER_ENABLED) over hardcoding APP_ENV === 'local'.

Gotchas and Tips

• v1.1.0 is a maintenance release. The only behavioural change is the production warning badge (PR #35). All other changes are Dependabot bumps of dev tooling (pest, larastan, collision, pint, orchestra/testbench, phpstan-phpunit) and the runtime dependency spatie/laravel-package-tools (now ^1.92.0). No breaking changes, no deprecations, no migration steps required.
• The prod badge is not a lockout. Seeing the warning badge means your environment guard did not prevent the route from being reachable. Re-check config/web-tinker.php and your APP_ENV immediately.
• Cache the config in production. php artisan config:cache will freeze the enabled flag — a stale config cache is the usual reason a supposedly-disabled tinker still loads.
• Don't rely on middleware order alone. The web middleware group includes CSRF/session handling; if you add auth middleware, ensure the route still receives the session cookie in your browser context or you'll get redirect loops.
• spatie/laravel-package-tools bumped to ^1.92.0. If you're on a Laravel/PHP combination that pins an older minor, run composer update spatie/laravel-package-tools and re-run your test suite — this is the only runtime dependency change in this release.
• Debugging an empty REPL or 404s: check php artisan route:list | grep tinker, confirm the service provider is auto-discovered (composer install after adding the package), and clear route:cache.
• Extension points: the published config is the primary extension seam (route path, middleware, environment gate). If you need custom output formatting or a different UI, the package's views are publishable (--tag="web-tinker-views") — prefer overriding views over forking.
• Never commit APP_ENV=local overrides or enabled config to .env.example that might be copied into shared environments; the new prod badge exists precisely because people have shipped this to production by accident.