Laravel Web Tinker Laravel Package

Getting Started

Install the package in your local environment using Composer (it’s intended for dev use only):

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

Then run the installer to publish the frontend assets and set up the route:

php artisan web-tinker:install

By default, the Web Tinker UI is accessible at /tinker and only in the local environment. Open that path in your browser to get started—no authentication needed locally. Start typing PHP code (e.g., User::first()) and hit Shift + Enter to execute.

Implementation Patterns

• Local REPL for debugging: Replace terminal php artisan tinker sessions with a visual, sessioned interface. Write multi-line snippets, inspect return values and exceptions inline, and repeat with slight variations—ideal for exploring Eloquent relationships or testing small business logic.

• Configuration-driven context: Extend functionality by publishing the config and adjusting the output_modifier to prepend timestamps, log IDs, or contextual data. Example custom modifier:

  // app/OutputModifiers/AppendUser.php
  namespace App\OutputModifiers;
  
  use Spatie\WebTinker\OutputModifiers\OutputModifier;
  
  class AppendUser implements OutputModifier
  {
      public function modify(string $output = ''): string
      {
          return $output . "\n→ Authed: " . auth()->user()?->email ?? 'Guest';
      }
  }
  

  Then set 'output_modifier' => \App\OutputModifiers\AppendUser::class in config/web-tinker.php.

• Secure staging access (advanced): To enable Web Tinker in non-local envs (e.g., staging), define a viewWebTinker Gate (in AuthServiceProvider), set 'enabled' => true, and restrict via middleware (e.g., only admins). Never use in production with real data.

• CLI/IDE parity: Use the /tinker page to validate how artisan commands or queued jobs behave before committing—especially helpful for confirming database state changes or observing side effects without leaving the browser.

Gotchas and Tips

• Security first: This executes arbitrary PHP—never install on production. The config defaults enabled to APP_ENV === 'local' for a reason.

• Hanging requests? In Docker or CI environments, ensure the custom ExecutionLoopClosure is used (fixed in v1.10.2+); avoid custom PsySH shells unless necessary.

• Output formatting quirks: HTML injection is blocked since v1.9.1 (output is purified client-side). Whitespace tags like <whisper> and noisyPsySH output like INFO Ctrl+D are auto-stripped.

• Middleware customization: Use the middleware config key to add things like rate limiting or audit logging, but preserve the built-in Authorize middleware for access control.

• Custom PsySH config: Set config_file in the config (e.g., '.psysh.php' in project root) to tune autocomplete, history path, or include aliases—this helps avoid permission errors like Writing to /var/www/.config/psysh is not allowed.

• Theme and UX: Use 'theme' => 'auto' to respect system preference. The Draggable gutter and autofocus reduce friction during extended sessions. Press Ctrl+Enter to send code; Shift+Enter inserts line breaks.

• Testing: If writing custom output modifiers or middleware, run unit tests locally—composer test runs the suite. Ensure your Laravel version is supported (see latest release notes: Laravel 13 support added in v1.10.5).