Pulse Laravel Package

Getting Started

This is a Blade + Tailwind UI component package (underline-style text inputs, checkboxes, and similar form controls), not a service-provider-heavy backend package. The integration surface is small: install, make Tailwind aware of it, build, use.

1. composer require the package, then check for a publishable config/views tag in the package README (vendor:publish). Publish only what you intend to own — see gotchas.
2. Add the package's view path to tailwind.config.js content globs. If you skip this, the component renders unstyled and you'll waste time debugging "broken" markup that is actually just purged classes:

   content: [
     './resources/**/*.blade.php',
     './vendor/vendor-name/package-name/resources/views/**/*.blade.php',
   ],
   

3. Run your asset build (npm run dev / vite build). Compose the package's CSS entry if it ships one, or rely on your own build picking up the classes.
4. First use case: drop the underline input into your login form and test it with a real browser autofill, not just typed input. That is the exact scenario this release fixes, and it's the fastest way to confirm your Tailwind build actually contains the new arbitrary-variant classes.

Where to look first: the package's resources/views (or src/View/Components) to see what props/slots exist, and its tailwind.config.js / CSS entry to see whether compiled CSS is shipped or expected to be built by you. That single question determines your upgrade workflow forever after.

Implementation Patterns

Wrap, don't scatter. Create a thin app-level component (<x-form.input-underline>) that forwards props to the package component and merges your standard attributes. When the package changes markup (as it did twice in this patch series), you fix one file instead of forty forms.

{{-- resources/views/components/form/underline.blade.php --}}
<x-package::input-underline
    {{ $attributes->merge(['class' => 'w-full', 'autocomplete' => 'off']) }}
/>

Centralize autofill handling. Because the autofill fix lives in Tailwind arbitrary variants baked into the component, don't re-declare :-webkit-autofill styles in your app CSS — you'll fight the package and lose on specificity. If you need a different autofill background (dark mode), override the CSS custom property the component reads, not the variant.

Pair with Livewire/Fortify by keeping wire:model and name passthrough. These components are usually attribute-bag based; verify $attributes falls through so validation state (@error, aria-invalid) still works. If it doesn't, wrap and pass explicitly.

Form layout pattern: use the package's checkbox for terms/remember-me and the underline input for credentials, and put spacing on a wrapping <div> rather than the component, so the component's internal sizing (including the resized checkmark) isn't disturbed.

Test autofill deliberately. Normal fill() in Playwright/Dusk doesn't reproduce browser autofill. Verify with saved credentials in Chrome, or use a small script to set :-webkit-autofill state via Chrome DevTools Protocol. Add a visual snapshot so the next silent regression is caught.

Gotchas and Tips

The compiled-CSS rebuild trap — this is the headline lesson. v1.0.2 exists because the v1.0.1 autofill fix "never actually shipped": the source classes were correct but the CSS wasn't rebuilt. Concretely:

• If the package ships prebuilt CSS, upgrading means republishing/re-copying that asset, not just composer update. Check the publish tag and run vendor:publish --force for the asset group (never --force blindly across all groups).
• If you build the CSS, composer update alone changes nothing until npm run build runs. Wire the build into your deploy pipeline so a dependency bump can't silently no-op.
• After upgrading, php artisan view:clear and bust any CDN/asset-version cache. Compare the built file's hash before and after.

Tailwind version floor. The fix uses arbitrary variants ([&:-webkit-autofill]:... / [&:autofill]:...), which need Tailwind 3.1+. On older Tailwind the classes are silently dropped — no error, just a light-yellow input in production. Verify in the built CSS output that the selector exists:

grep -c 'webkit-autofill' public/build/assets/*.css

WebKit-only coverage. :-webkit-autofill covers Chrome/Edge/Safari. Firefox uses :autofill, and Safari has quirks around -webkit-text-fill-color and box-shadow-based background overrides. If autofill looks right in Chrome but wrong in Firefox, that's expected unless the package also ships the standard selector — check the changelog before filing a bug.

Don't edit vendor/. Changes vanish on the next composer update. Override via published views or by wrapping the component. If you must patch, fork and use a VCS repositories entry.

Checkmark sizing is a visual judgment call, not a contract. v1.0.2 resized it "after live review." Sizing may be expressed in relative units, so it will shift if your parent sets a smaller font-size or your root font-size differs. Snapshot the checkbox at your actual body font-size, and re-check after any typography/theme change — small deltas here are easy to ship unnoticed.

Dark mode. Autofill overrides often hardcode a background. If you support dark mode, test autofilled inputs there specifically; the light-native-color bug this release fixes is most visible (and most jarring) on dark surfaces.

Extension point to prefer: CSS custom properties / a config array for color and radius, if the package exposes one. Those survive upgrades; class-name overrides into the component's internals do not.

Watch the patch cadence. Two CSS-level corrections in consecutive patches (v1.0.1, v1.0.2) with one failing to ship suggests a packaging/build-pipeline weakness. Pin the version ("^1.0.2"), read release notes rather than assuming composer update delivered the fix, and keep the visual snapshot test.