Livewire Dusk Extension Laravel Package

Getting Started

This is a pre-1.0 package (v0.3.0), so treat the public API as provisional until it hits 1.0.

1. Install and inspect the service provider first. Run composer require for the package, then open its ServiceProvider to see what gets registered — component resolution, config publishing, and any Blade/view namespaces almost always live there.
2. Publish config (if offered). php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" and read the config file top to bottom; it's usually the fastest map of the package's capabilities.
3. Find the component entry point. Since v0.3.0 is specifically about component parameters, locate the component base class / renderer and confirm how parameters are declared (constructor args, data()-style method, or public properties).
4. First use case — the thing v0.3.0 unlocks: pass a value in from a Blade view rather than hard-coding it inside the component:

<x-package-component :title="$post->title" :items="$post->tags" />

Before v0.3.0 this would have been impossible; any component whose output depended on caller data had to be duplicated or wrapped. Start by refactoring one hard-coded component into a parameterised one — that's the smallest change that proves the release works for you.

Where to look first when something breaks: the compiled view cache (storage/framework/views). If a parameter appears to be ignored, clear it (php artisan view:clear) before assuming the package is at fault.

Implementation Patterns

Scalar parameters for presentational components. The straightforward case: pass a string/number and let the component own the markup. Keep the component dumb — formatting, escaping, and layout only. This is where parameter support pays off fastest, because presentational components are the ones most often re-used with different labels and copy.

Collection/array parameters for list rendering. Passing a collection (e.g. :items="$posts") inside a component that handles @foreach centralises empty-state handling and pagination markup in one place. Guard against null at the component boundary rather than at every call site.

Bound vs. literal attributes. Follow Blade's own convention unless the package docs say otherwise:

• :attr="$value" — evaluates a PHP expression.
• attr="value" — passes the literal string.

Mixing these up is the single most common source of "the parameter arrives as the string '$posts'" bugs. Verify early which syntax the package actually parses.

Defaults for backward compatibility. When adding a parameter to an existing component, give it a sensible default so existing call sites keep rendering. In a v0.x package this also limits the blast radius if the maintainer changes the parameter contract again in v0.4.

Composition — component calling component. Once parameters exist, compose: a <x-card> that forwards :title and :footer into inner components. This is where you get leverage, but also where parameter plumbing becomes hard to follow. Keep forwarding shallow; two levels deep is usually enough.

Integration tips.

• Resolve parameters in the controller/view-model, not with method calls inside the Blade attribute (:items="$user->posts()->where(...)->get()"). Keeping queries out of templates also keeps them testable.
• Because the package is at 0.3.x, pin the version in composer.json ("^0.3" rather than "*") and review each release note before upgrading — the changelog is short and moves fast.
• Add a smoke test that renders each parameterised component with representative inputs. Component parameter parsing is exactly the sort of thing that regresses quietly between minor versions.

Gotchas and Tips

v0.x means no stability guarantee. Three minor releases in and the parameter API is brand new. Assume the attribute syntax, parameter naming, or component base class may change before 1.0. Wrap your own components in your app so the package's surface area is confined to a small number of files.

Kebab-case vs. camelCase mismatch. Many component systems convert :post-count into a $postCount property (and vice versa). If a parameter silently arrives as null, check the name conversion first — it's the highest-probability cause.

Escaping and raw output. Passing a value in does not mean it is safe to echo. Confirm whether the component escapes by default; if you need HTML, prefer an explicit slot or a dedicated raw parameter over {!! !!} scattered through the component.

Type coercion. Attributes coming from Blade are strings unless explicitly bound. :count="3" and count="3" may behave differently inside the component. If the component type-hints an int, a literal attribute can throw a TypeError — bind, or cast inside the component.

Missing/undefined parameters. Find out what happens when a parameter is omitted: silent null, a default, or an exception. In an early-stage package this is often undocumented and inconsistent between components. Test it once, write it down.

View cache staleness. After upgrading to 0.3.0, run php artisan view:clear. Compiled components that predate parameter support can produce confusing partial output.

Debugging approach. Dump the resolved parameter set at the top of the component's render method (dump(get_defined_vars())) rather than inside the consuming view — it separates "the caller didn't pass it" from "the component didn't receive it."

Extension points. If the component base class exposes a data()/resolve() hook, prefer overriding that over modifying published views — it survives package updates. Published views, by contrast, will not be updated when the maintainer fixes them upstream, so keep a note of anything you publish.

Upgrade checklist for each 0.x release. Read the changelog, clear compiled views, run the component smoke tests, and skim the package's own test suite diff if the repo is public — in pre-1.0 packages the tests often document behaviour the README hasn't caught up with yet.