Noty Laravel Package

Getting Started

1. Install the package

composer require sarfraznawaz2005/noty

Laravel 8's auto-discovery should register SarfrazNawaz2005\Noty\NotyServiceProvider. If you are on an older Laravel or have discovery disabled, add the provider and the Noty facade alias to config/app.php manually.

2. Publish config and assets

php artisan vendor:publish --provider="SarfrazNawaz2005\Noty\NotyServiceProvider"

Check the output carefully — config is published to config/noty.php, and the package's JS/CSS (or a Blade partial) lands under resources/views/vendor/noty and/or public/vendor/noty. If the package exposes separate tags (--tag=config, --tag=assets), run them individually so you can skip overwriting an already-customised config.

3. Wire it into your layout

Put the package's Blade include/partial in your master layout, after your main scripts but before </body> (or in the @stack('scripts') region if the package supports it):

{{-- resources/views/layouts/app.blade.php --}}
    @include('noty::noty')
</body>

This is the single most important step. If the partial is missing, Noty::success(...) will silently queue a session message that nothing ever renders.

4. First use case — flash a message from a controller

public function store(Request $request)
{
    // ... validation + persistence ...

    Noty::success('Record saved successfully.');

    return redirect()->route('records.index');
}

The message is flashed to the session, survives the redirect, and is rendered as a Noty toast on the next page load. That redirect-then-toast loop is the package's primary purpose.

Where to look first: config/noty.php (theme, layout, timeout, animation) → the published Blade partial (how messages are read from the session) → the Noty facade class (which helper methods and static methods exist).

Implementation Patterns

Controller → redirect → toast (the canonical flow)

Flash methods are session-backed, so they pair naturally with PRG (post/redirect/get):

public function update(Request $request, Post $post)
{
    $post->update($request->validated());

    Noty::success('Post updated.');
    return redirect()->route('posts.edit', $post);
}

Because they are session flashes, calling Noty::success() mid-request will not pop up on the current page — it appears on the next rendered response. Treat it as a flash API, not a live notification API.

All four levels, called from the same action

if ($imported === 0) {
    Noty::warning('No rows were imported — check the file headers.');
} elseif ($imported < $total) {
    Noty::info("Imported {$imported} of {$total} rows.");
} else {
    Noty::success("All {$total} rows imported.");
}

if ($skipped) {
    Noty::error("Skipped {$skipped} invalid rows.");
}

return back();

Stacking multiple calls in one request is the practical way to report partial successes; each call becomes its own toast on the redirect target.

Helper function for views and closures

If the facade is awkward in a place where you don't want an import (e.g. a Blade template, an event listener, a queued job that has no DI context), the package's helper gives you the same API:

@if(session('billing_failed'))
    @php noty()->error('Payment could not be processed.') @endphp
@endif

Prefer the facade inside services/controllers (it's testable and mockable); use the helper in views where a use statement is noise.

Centralising message vocabulary

In a multi-tenant or localised app, wrap the package rather than calling Noty:: from fifty controllers:

// app/Support/Flash.php
class Flash
{
    public static function saved(string $model): void
    {
        Noty::success(__(':model saved.', ['model' => $model]));
    }

    public static function failed(string $reason): void
    {
        Noty::error($reason);
    }
}

This keeps message tone, translation keys, and any future swap to a different toast library in one file. It also means a future upgrade of noty doesn't ripple through controllers.

Mapping Laravel's built-in validation errors to toasts

Validation failures already arrive as session errors. Two options: let the package's partial read them (if it does — check the partial's source), or explicitly bridge them in a middleware/FormRequest::failedValidation:

protected function failedValidation(Validator $validator)
{
    Noty::error($validator->errors()->first());

    throw (new ValidationException($validator))
        ->errorBag($this->errorBag)
        ->redirectTo($this->getRedirectUrl());
}

Be careful not to double-render — if the partial also renders $errors, you will get two toasts for the same failure.

Global config vs per-call overrides

Set opinionated defaults in config/noty.php (theme, layout, timeout) so every toast in the app looks consistent. Escape the config at the call site only for genuinely special cases:

noty()->success('Export ready.')->timeout(10000);

Whether fluent overrides exist depends on the version you install — inspect the facade's class before assuming. If they don't, use the config file plus a dedicated Flash::longLived() wrapper that temporarily overrides config via Config::set() before calling the facade.

Config publishing workflow

php artisan vendor:publish --tag=noty-config
php artisan config:clear

Publish once, commit config/noty.php to the repo, and stop there. Re-publishing later will clobber your theme/timeout choices; if you need to re-publish a newer default, diff it against what you have rather than overwriting.

Gotchas and Tips

Noty:: calls are session flashes — they do not "fire" in place. The most common beginner bug is calling Noty::success() from a method that returns a view without a redirect and then wondering why nothing appears on that page or why it shows up on the page after next. Always pair the call with a redirect, or accept that the message renders on the following request.

A missing layout include is silent. No JS error, no exception, no log line — the toast simply never renders. If "notifications don't work," verify in this order: (1) partial is in the layout, (2) partial is inside the rendered layout for that route (some auth pages use a different layout), (3) php artisan view:clear, (4) the browser network tab shows the Noty JS/CSS loaded without 404, (5) the session actually contains the flash key.

Assets are a published-copy problem, not a CDN problem. If you publish Noty's JS/CSS to public/vendor/noty, those files are static from that point on. A composer update of the package will not refresh them — you must re-publish assets. Conversely, some versions load Noty from a CDN; if you operate in an air-gapped or CSP-restricted environment, check the partial for external <script src> tags before deploying.

Script ordering matters more than the config. The include must come after Noty's JS is defined and after jQuery only if the version in use requires it. Putting the include in <head> is the classic cause of Noty is not defined. If you use @stack('scripts'), make sure the package's partial supports the stack or you'll end up with duplicate initialisation on some pages.

Message content is user-facing and often user-derived. If you interpolate a model name, a filename, or anything else that originated from a request into a toast, check whether the partial escapes it. Toast libraries that build HTML strings can turn Noty::error($request->input('name')) into stored XSS. When in doubt, e() on the way in.

This package's last release targets Laravel 8 (2020). On Laravel 9+ you are off the supported path. Practical consequences: the service provider may not declare boot/register compatibly, the config may use removed helpers, and you lose the auto-discovery guarantee. If you're on 9+, do a short spike — install in a throwaway app, confirm the partial renders, and check the package's composer.json constraints with composer why-not. If it fails, pin illuminate/support in a fork or vendor the single Blade partial into your own views and keep only the JS.

config:cache in production freezes your Noty settings. If you tweak config/noty.php on a live box and nothing changes, run php artisan config:cache again — or config:clear while debugging. This bites people who edit config directly on a deployed server.

Watch for duplicate toasts after a back() from validation. If your FormRequest throws and you also call Noty::error() in failedValidation, and the view partial independently renders session('errors'), the user sees two messages per field group. Pick one bridge: either let the partial handle $errors, or handle it yourself — never both.

Session lifetime and queue behaviour. Because messages ride the session flash, a driver change (file → redis → database) can expose problems during a deploy: if sessions are cleared or the user's session is dropped between the POST and the redirect (load-balanced workers without shared sessions), the toast disappears. Test in staging behind your real load balancer, not just on a single local server.

Testing toasts. Don't assert on rendered JS. Assert on the session flash key instead — it's fast, framework-level, and immune to theme changes:

$this->post('/posts', $data)->assertRedirect('/posts');

$this->assertEquals('Post saved.', session('noty')['success'] ?? session('success'));

Inspect the actual flash key name once (dump session()->all() after a call) and codify it in a helper trait; that keeps your tests stable if you ever swap the toast package.

Extension point if the built-in levels aren't enough. Every Noty:: helper is a thin wrapper over a generic flash call. For a "custom" type or a toast with extra Noty options, drop to the underlying generic method (typically Noty::message($text, 'type', $options)) rather than adding a parallel notification mechanism. Keeping one code path in your Flash wrapper makes a future migration to Livewire/Alpine-based toasts a one-file change.