Slidewire Laravel Package

Getting Started

Install and scaffold in three commands

composer require wendelladriel/slidewire
php artisan make:slidewire demo/product-launch --title="Product Launch"

The command writes resources/views/pages/slides/demo/product-launch.blade.php. Then register a route:

Route::slidewire('demo/product-launch');

That's the whole happy path — no separate frontend build, no Vite entry, no JS framework. If you already have Livewire 3.x installed, assets are already wired.

Where to look first

1. config/slidewire.php → presentation_roots. The presentation key demo/product-launch maps to <root>/demo/product-launch.blade.php. Every deck you add is discovered from here, so this is the single knob that decides your authoring layout.
2. The generated Blade file itself. It's the contract: one <x-slidewire::deck> wrapping one or more <x-slidewire::slide>. Everything else (themes, transitions, fragments, backgrounds) is an attribute or nested component inside that file.
3. Docs at https://slidewire.dev — specifically the component reference and the theme schema. The package's own AGENTS.md/skill files are also a genuinely useful crib sheet for component names and attributes.

First use case

Pick something internal and behind auth — onboarding material, an architecture walkthrough, a release/roadmap deck. Do not start with a public marketing deck. SlideWire renders a full-page Livewire component, which means JavaScript is mandatory and there is no built-in SEO metadata; internal auth-gated content sidesteps both problems and lets you prove the authoring workflow before anyone outside the team sees it.

One setup step people miss

Add the package sources to your Tailwind entry (resources/css/app.css) immediately:

@import 'tailwindcss';

@source '../views';
@source '../../vendor/wendelladriel/slidewire/resources/views/**/*.blade.php';
@source '../../vendor/wendelladriel/slidewire/src/**/*.php';

Without these, the first-party UI components render as correctly-marked-up but visually broken HTML. This is not a bug — Tailwind simply never sees the classes. Put it in the setup checklist, not in a Slack thread.

Implementation Patterns

Compose the deck with the opinionated components, don't hand-roll layout

The first-party set is where most of your authoring time gets saved:

<x-slidewire::deck theme="midnight">

    <x-slidewire::title-slide
        overline="Engineering"
        title="Q3 Roadmap"
        subtitle="What ships, what slips, what's next"
        presenter="Jane Doe — Platform" />

    <x-slidewire::agenda-slide>
        <x-slidewire::agenda-item>Shipped</x-slidewire::agenda-item>
        <x-slidewire::agenda-item>In flight</x-slidewire::agenda-item>
        <x-slidewire::agenda-item>Next</x-slidewire::agenda-item>
    </x-slidewire::agenda-slide>

    <x-slidewire::two-column-slide title="Migration status">
        <x-slot:left>
            <x-slidewire::markdown>
### Done
- Auth cutover
- Queue workers
            </x-slidewire::markdown>
        </x-slot:left>
        <x-slot:right>
            <x-slidewire::panel variant="elevated">
                Live metric here
            </x-slidewire::panel>
        </x-slot:right>
    </x-slidewire::two-column-slide>

</x-slidewire::deck>

timeline-slide/timeline-item, steps-slide/step-item, and media-split-slide cover the other 80% of internal-deck shapes. Reaching for raw <div> + Tailwind should be the exception, not the default.

Let the deck read from the application

This is the reason to use SlideWire over Keynote at all: the deck can query the app it lives in.

<x-slidewire::slide>
    <x-slidewire::panel variant="glass">
        <p class="text-sm text-slate-400">Active subscriptions</p>
        <p class="text-5xl font-semibold">{{ Number::format($activeSubs) }}</p>
    </x-slidewire::panel>
</x-slidewire::slide>

Bind through a dedicated Livewire component or a @php block calling a scoped query — but keep it to a bounded, cheap read. Don't put business logic or N+1 queries in a slide; a slow slide is a visibly frozen presentation. Wrap anything failable (external API, metrics store) so the deck renders a fallback rather than a 500 mid-pitch.

Use deck-level defaults, override per slide

Every meaningful setting has config → deck → slide precedence (auto-slide timers most explicitly). Set theme, transition, and transition speed once on <x-slidewire::deck> and override on the rare slide that needs to differ:

<x-slidewire::deck theme="midnight" transition="fade" :transition-speed="300">
    ...
    <x-slidewire::slide transition="zoom" auto-slide="8000">

This keeps the file diffable and means a theme change is one edit, not forty.

Vertical stacks for drill-down

Use <x-slidewire::vertical-slide> to nest detail under one horizontal column — one roadmap lane, several slides of detail. Down/up navigates the stack; left/right moves between columns. This is the pattern that keeps a 40-slide deck from feeling like a 40-step march.

Fragments for pacing

<x-slidewire::fragment> reveals content on the next advance, which is how you keep a dense architecture slide readable. Note that fragments participate in navigation (v1.2.0 made navigation fragment-aware), so "next" may consume several presses before the slide changes — intentional, but worth knowing when someone says navigation is "stuck."

Keep content thin and portable

Write slides as Blade that composes components plus Markdown, with data access at the edges. Since v1.4.0 you can also author Markdown slides and compose decks, which is a good escape hatch for text-heavy content and for contributors who aren't comfortable in Blade. If you ever have to leave the package, thin content migrates; a deck full of embedded PHP logic does not.

Codify a template early

After the first deck works, standardize: route naming, auth middleware on Route::slidewire(), one theme, one component vocabulary, one place where live data gets fetched. The leverage here is many decks from one shell, not one beautiful deck.

Gotchas and Tips

Missing styles almost always means missing @source. If components render unstyled, check resources/css/app.css before you check the package. This is the single most common integration failure.

Pin the version and read the release notes. The 1.x line is still moving (markdown/composed decks in 1.4.0, media split in 1.3.1, first-party UI components in 1.3.0). Specifically, pin ≥ 1.4.2 — that release fixed slide offsets accumulating after repeated navigation, which is the kind of bug that only shows up in a live rehearsal.

Test php artisan config:cache explicitly. Theme and typography config are resolved through DTOs; v1.3.2 fixed DTO serialization for config caching. Cached config is a real production path and a distinct code path. Add it to your deploy checklist, and when in doubt:

php artisan optimize:clear

That clears the "I changed the theme and nothing happened" class of problems.

Browser tests mean Chromium in CI. The package's own gates are composer lint, composer test, composer test:browser; the browser suite needs npx playwright install chromium. If you write your own navigation tests, budget for Node + a headless browser in the pipeline before you promise them.

No export, no SEO, JS required. HTML/JS output only. If a stakeholder asks for PDF or PPTX handoff, that's a compensating workflow you must define up front — a slide-per-page print stylesheet, screenshots, or a separate tool. Equally, don't route SEO-critical or accessibility-mandated public content through this; there are no documented ARIA guarantees.

Decks are trusted code. A .blade.php deck is a template-execution surface — it can run PHP. Non-engineers authoring decks without review is an XSS and code-execution risk, and {!! !!} in a slide is the same footgun it is anywhere else in Blade. Markdown slides are safer for non-technical authors, but still route them through review.

Don't fight the theming system in week one. SlideWire ships theme presets with typography controls, but if your brand system has strict design tokens, spike the theming before committing. Brand-exact layouts may still need custom Blade components and CSS overrides layered on top. Find that out on deck #1, not deck #15.

Check small screens. v1.0.1 fixed slide overflow on smaller viewports and v1.2.0 improved mobile scroll, but dense slides still break first on a laptop at 1280×720 projected. Test at your actual presenting resolution and at half of it.

Debugging a blank or broken deck: confirm the presentation key resolves to a real file under presentation_roots, confirm the route was registered with Route::slidewire(), confirm the Livewire component mounted (check the network tab for the Livewire asset), then clear caches. Those four cover nearly every "it doesn't work" report.

Dependency risk is real. 142 stars, zero dependents, one primary maintainer, young 1.x. Isolate it: pin the version, keep deck content thin, and name an owner for upgrades. Also verify the actually-installable version on Packagist during your dependency audit — the published release metadata lists dates beyond the present, so don't pin from the changelog alone.