Laravel Support Laravel Package

Getting Started

1. Install the package and let Laravel discover its service provider:

   composer require <vendor>/<package>:^1.1
   php artisan vendor:publish --tag=<package>-assets   # front-end assets
   php artisan vendor:publish --tag=<package>-config   # optional
   

2. Look first at the package's service provider and its config/<package>.php. The provider is where the asset/script registrations live — that is the same code path that the v1.1.4 "Fix use of jQuery slim" release touched, so read it before assuming anything about which jQuery build gets injected.

3. Check the published asset directory (typically public/vendor/<package>/) and any Blade component or @push('scripts') block the package registers — that's where the jquery.slim reference now correctly resolves.

4. First use case: wire the package into a single layout, confirm exactly one jQuery build is on the page, then convert one AJAX call to fetch/axios to verify the slim build is actually slim (no $.ajax).

{{-- resources/views/layouts/app.blade.php --}}
@stack('styles')
...
@stack('scripts')

Implementation Patterns

Lean on the slim build, not around it. jQuery slim drops ajax and effects. The intended pattern is: slim jQuery for DOM/selector/event work, axios (already in Laravel) or fetch for transport, and CSS transitions or the Web Animations API for animation. Treat that split as the package's opinion and follow it rather than bolting full jQuery back on.

Single load point. Register the package script once in your base layout and let Livewire/Alpine/other packages piggyback on the global $. Pushing the same script from multiple partials is the most common cause of "works on one page, broken on another."

Deferred, ordered loading. Put the package's script in a @push('scripts') stack rendered at the end of <body> (or use defer with a DOMContentLoaded guard). Anything custom you write must land after it, so keep your own scripts in a later push or a separate stack.

Vite integration. If you've moved to Vite, prefer importing the package's JS entry from resources/js/app.js and dropping the published copy entirely — but only after confirming the package's entry is ESM-friendly; otherwise keep the published asset route and load it via @vite-independent <script> tags.

Config-driven toggles. Where the package exposes a config flag for the jQuery variant or for asset auto-registration, use it instead of editing the published file — that keeps --force republishing safe.

Gotchas and Tips

• Slim has no $.ajax, $.get, $.post, $.getJSON. Any plugin or legacy snippet calling them fails with undefined is not a function. Search the codebase for those before upgrading; the v1.1.4 fix makes the slim build load correctly, which is precisely when previously-masked calls start throwing.
• Slim has no .animate(), .fadeIn(), .slideToggle(). Same failure mode. Replace with CSS classes or the Web Animations API.
• Double jQuery. A second full jQuery from a theme, an admin template, or an old bootstrap.js bundle silently overwrites $ and undoes the slim win. Verify with window.jQuery.fn.jquery and 'ajax' in window.jQuery in the console — the second check should be false.
• Publish-and-cache dance. After composer update, run php artisan vendor:publish --tag=<package>-assets --force (mind local customisations) and bump your asset version, or you'll be debugging a stale cached jquery.slim.js.
• config:cache traps. If the package reads asset paths or a jQuery-variant flag from config, a stale bootstrap/cache/config.php will keep serving the old behaviour. php artisan config:clear before concluding the fix "didn't work."
• Version pin the release. v1.1.4 is an asset-resolution patch; pin ^1.1.4 so you don't regress to a release that mis-resolves the slim build, and note it in your lockfile diff review.
• Extension points. Prefer the config flag / Blade stack / published assets trio before patching vendor files. If you genuinely need full jQuery, set the config to the full build (or exclude the package script) rather than appending a second copy.
• Debugging tip. Load the page with the network panel and confirm exactly one jQuery request, of size roughly a third less than a full build (~70KB vs ~30KB uncompressed). A full-size payload means something else is still pulling it in.