Pulsar Laravel Package

Getting Started

Start by reading the package README and the service provider before touching any markup. With only 27 stars and an unknown repository link, the source is your documentation: inspect vendor/jadu/pulsar/src, resources/views, resources/assets, and any config/pulsar.php after install.

1. Install with Composer and let Laravel auto-discovery register the provider:

   composer require jadu/pulsar
   

2. Publish what the provider exposes:

   php artisan vendor:publish --provider="Jadu\Pulsar\PulsarServiceProvider"
   

   Look for tagged publishes (config, views, assets) and prefer tags over a blanket publish so upgrades stay predictable.
3. Check the provider's boot() for loadViewsFrom, Blade::componentNamespace, directives, or asset registration. This tells you the exact component prefix and whether you need @pulsarStyles/@pulsarScripts-style directives or a Vite entry.
4. Add the package stylesheet/JS to your main layout in the correct order: package CSS first, application overrides second.
5. Render one component in isolation before integrating it into a real screen — a button or alert is enough to verify namespacing, asset loading, and attribute passthrough.

First real use case: build a single CRUD screen (index table + form) using only package components, then compare it against the package's own demo/markup examples. That exposes naming conventions, slot behaviour, and validation-state handling quickly.

Implementation Patterns

Wrap vendor components in app-level components. Do not scatter <x-pulsar::...> tags across hundreds of views. Create thin wrappers such as resources/views/components/ui/button.blade.php that proxy props and slots to the package component. When the package changes or you swap it out, you edit one file per component instead of grepping the codebase.

Treat the package as a presentation layer, not a form framework. Keep validation, authorization, and request handling in Laravel. Pass explicit props into components:

<x-ui.input
    name="email"
    :value="old('email', $user->email)"
    :error="$errors->first('email')"
/>

This keeps error display and old-input behaviour under your control rather than relying on undocumented package defaults.

Use slots for composition and the attribute bag for escape hatches. Most UI frameworks expose $attributes; pass class, id, data-*, and aria-* through so you can integrate with Alpine, Livewire, or your own JS without forking views. Named slots usually cover headers, footers, and actions in cards/modals/tables.

Theme via tokens, not view overrides. If the package ships CSS custom properties or Sass variables, override those in your app stylesheet. Published views should be a last resort — every published view becomes a file you must diff on upgrade.

Integrate with pagination and navigation deliberately. If the package provides paginator views, register them explicitly rather than assuming Paginator::defaultView() is changed. For navigation, build a small menu builder or config array and loop over package nav components; do not hand-write nav markup per page.

Test at the HTTP level, not the CSS level. Feature tests asserting assertSee('Save') and assertSee($user->email) catch broken component contracts. Use Dusk or Playwright only for interactive components like modals and dropdowns, where the package's JS behaviour matters.

Gotchas and Tips

• Pin the version. Low stars, unknown repository, and a future-dated release mean you should use an exact constraint ("jadu/pulsar": "1.2.3") and review the diff before upgrading. Vendor risk is the biggest concern here.
• Asset publishing drifts. If you publish assets to public/, they will not update with Composer. Either re-publish on every upgrade in CI or, better, import the package source into your Vite pipeline so builds are reproducible.
• Load order matters. Package CSS loaded after app CSS silently defeats your overrides. Verify the compiled bundle order, not just the Blade include order.
• Component name collisions. A package component named button can conflict with your own <x-button>. Always use the package's namespace prefix and check Blade::getClassComponentAliases() in Tinker if a component resolves unexpectedly.
• Clear caches after publishing or config changes. php artisan config:cache will freeze package config; run php artisan config:clear and php artisan view:clear when debugging why a published view or config value is ignored. Compiled Blade lives in storage/framework/views.
• Check for undocumented JS requirements. Modals, tooltips, and dropdowns often need a specific JS entry point or initialization call. If interactions fail silently, inspect the package's JS source for required data attributes.
• Do not strip accessibility attributes. When wrapping components, forward aria-*, role, and id through $attributes; wrapper components that swallow attributes break label association and focus management.
• Extension points to prefer: config values, CSS tokens, component wrappers, and Blade macros. Avoid editing vendor/ and avoid publishing every view "just in case."
• Debugging checklist: confirm the provider is discovered (php artisan about), confirm the view namespace with view()->exists('pulsar::...'), dump $attributes inside a wrapper, and compare rendered HTML against the package's own examples.