- How do I install and set up Laravel Toaster Magic?
- Install it with Composer using composer require devrabiul/laravel-toaster-magic, then publish the package assets and config with a single vendor:publish call. Add the two Blade directives, ToastMagic::styles() and ToastMagic::scripts(), to your base layout so the CSS and JS runtime are injected. After that you can flash toast messages from your controllers or Livewire components, and most developers have a working setup in well under a day.
- Does Laravel Toaster Magic require jQuery, Bootstrap, or Tailwind CSS?
- No. The package is explicitly dependency-free and ships its own CSS and JavaScript runtime, so it does not require jQuery, Bootstrap, or Tailwind CSS. That means it can sit alongside an existing design system, a custom CSS build, or a utility framework without conflicts. The only runtime requirement is that the Blade style and script directives are rendered in your layout.
- Which Laravel and PHP versions does Laravel Toaster Magic support?
- The package requires PHP ^8.0 and declares illuminate/support support from ^8.0 through ^13.0, so Composer will warn rather than silently install on an unsupported stack. That range covers current Laravel releases and gives a clear upgrade path. Always confirm the exact version and release date on Packagist before pinning it in a production composer.json.
- Does Laravel Toaster Magic work with Livewire?
- Yes. Livewire v3 and v4 are supported through event dispatch, so you can trigger toasts directly from Livewire components without a page reload. Livewire support is optional and gated by the livewire_enabled and livewire_version config values, which keeps the dependency conditional. If you are not using Livewire, the package works fine with plain controller-driven session flashes.
- How do I change the toast theme, animation, or enable dark mode?
- Themes and animations are configurable: the package ships 8+ themes including iOS, Neon, Glassmorphism, Material, Minimal, and Neumorphism, plus slide, fade, pop, and bounce entrance and exit animations. Global defaults live in the published config file, so you can set the theme and animation once for the whole app. Dark mode is enabled with a theme="dark" attribute on the body element rather than by prefers-color-scheme or a CSS class.
- Is Laravel Toaster Magic accessible to screen reader users?
- The README does not document ARIA live-region or role="status" behavior, nor keyboard focus handling for the close button, so accessibility should be verified rather than assumed. Before shipping it to any WCAG-scoped surface, test toast announcements with a screen reader and confirm the dismiss control is reachable by keyboard. If those checks fail, you would need to patch the runtime or add your own ARIA attributes.
- Is it safe to display user-supplied content in a toast?
- Be careful here. Toast headings and descriptions are rendered as HTML by design, with newlines converted to line breaks, so any unescaped user input passed into a toast is an XSS vector. Always escape or sanitize dynamic values before flashing them. A future v3.0 release is slated to escape by default as a breaking change, so plan for that behavior shift.
- Will the inline styles and scripts work with a strict Content Security Policy?
- The ToastMagic::styles() and ToastMagic::scripts() directives emit inline markup, so a strict CSP without nonces or hashes will block them. If your app enforces such a policy, you will need to extract the compiled assets and serve them yourself, or add nonce support around the emitted tags. Test this early in a spike, because a blocked script tag means no toasts render at all.
- How are the CSS and JS assets published, and does that work in containers?
- Assets are published to the public directory on first page load and re-published when the package is updated, which means a filesystem write at request time. On read-only or immutable container filesystems that publish step will fail or silently diverge, and across multi-node deployments behind a CDN the copies can drift out of sync. The safer pattern is to run vendor:publish during your build or CI step and disable runtime publishing.
- When should I avoid Laravel Toaster Magic, and what should I use instead?
- It is a strong fit for server-rendered Laravel monoliths and Livewire apps, but a weak fit for API-only backends and decoupled SPA front ends such as React, Vue, or Inertia. There is no npm distribution and no published JSON contract; the JavaScript API only exists after the Blade-injected script tag loads, and it registers a bare global ToastMagic that could collide with other code. For those stacks, use a JavaScript-first toast library installed through npm instead.