Laravel Video Demos Laravel Package

Getting Started

Install the package with Composer, publish its config and migrations, then set the VIDEO_DEMO_* environment variables for the studio, sample database, and AI provider. The first place to look is the published config/video-demo.php and the studio route/service provider registration; those define how plans are stored, how sample data is seeded, and which auth strategy the recorder uses.

A good first use case is a simple authenticated CRUD flow: sign in, open a list page, create a record, and show the result. Start with VIDEO_DEMO_SIGN_IN=session for a standard Laravel app, seed sample data, and let the planner generate a short video. Keep rehearsal enabled (the default) so the plan is validated against a copy of the sample database before any recording or voice-over is produced. If the app has a separate Vue/React frontend, set VIDEO_DEMO_FRONTEND_URL early; otherwise leave it unset and nothing changes.

Implementation Patterns

Use the package as a demo-video pipeline rather than a browser automation script: define a plan in terms of user-visible steps, let the AI resolve vague labels by looking at pages only when needed, rehearse on sample data, then record. The rehearsal step is the main day-to-day quality gate: it is cheap, costs no AI, and catches broken selectors before voice-over generation. Treat a failed rehearsal as a normal repair cycle and keep limits.max_repairs realistic.

For auth, choose the sign-in strategy that matches the app: session for standard Laravel and Sanctum cookie-based SPAs, sanctum-token or jwt for token-based frontends, and custom with VideoDemo::signInUsing(...) for Passport, SSO, or bespoke headers/cookies/localStorage. For separate frontends, configure VIDEO_DEMO_FRONTEND_URL and rely on the recorder’s signed header so API calls from the frontend reach the video’s sample database without CORS changes.

When a plan depends on translated labels, component-rendered text, database-driven labels, or a separate frontend, enable page looks (default: up to three per video). This is useful for AI planning but should be budgeted; set VIDEO_DEMO_PAGE_LOOKS=0 where label ambiguity is low. For write-heavy demos, let app-refused changes fail the step: a 4xx on POST/PUT/PATCH/DELETE gives the AI Laravel’s message and a chance to repair the plan before a bad video is recorded.

Gotchas and Tips

Rehearsal counts toward limits.max_repairs and does not run for videos on your own data or for plans that are recorded again as they were. It can be disabled with VIDEO_DEMO_REHEARSE=false, but doing so removes the cheapest validation pass. Page looks cost roughly a cent each and are capped at three per video by default; set VIDEO_DEMO_PAGE_LOOKS=0 if cost matters more than AI label resolution.

With separate frontends, Sanctum tokens expire after an hour and expired recorder tokens are removed; custom sign-in must explicitly provide headers, cookies, or localStorage values. A 4xx from a write request fails the step, but GETs, Precognition validation, broadcasting sign-in, and guest 401s are left alone. When debugging, read the step failure text for the preceding app refusal, such as a 419 CSRF mismatch or a 422 validation error, and check whether the frontend redirected to its own sign-in page. The v0.18.0 label fix means role-plus-label targeting now selects the labelled element rather than the first element of that role; older plans that depended on the first-match fallback may need review.