vue-notification: Vue 2 toast notifications driven by a $notify API

The problem: notifications triggered from outside a component tree

Most toast libraries make you render a container and then reach it through a ref, a composable, or a store. vue-notification installs itself on the Vue prototype instead. After Vue.use(Notifications), every component can call this.$notify(...), and files that are not components (a router guard, an axios interceptor, a plain module) can call Vue.notify(...) after importing Vue. The README gives exactly that router example.

The audience is a Vue 2 application that already has a place to put a global component and wants notification calls to be one line anywhere in the codebase. The plugin ships a single global component, <notifications/>, which you place once in App.vue. Everything after that is either a call site or a prop on that one element. There is no provider, no context, no queue object to pass around.

How the $notify API and the holder component divide the work

The split is deliberate: the component owns placement and presentation, the API owns content. On the component you set position, width, classes, duration, speed, animation-type, animation-name, animation, max, reverse, ignoreDuplicates, and closeOnClick. On the call you set group, title, text, type, duration, speed, and data. Call-level duration and speed override the component-level values, which is how you make one notification sticky while the rest disappear after the default 3000 ms.

Groups are the interesting part. Each <notifications group="..."/> creates a named holder, and a call with the same group lands there. The README's own example puts authentication errors in a top holder and app notifications in a bottom-right holder. A call with clean: true and a group empties only that group. The type property is not a semantic category inside the library; it is appended as a CSS class on the .vue-notification element, so styling is your job and the library stays out of it.

Duration accepts a negative number, which the README says keeps the notification on screen forever or until it is clicked. That is a real behaviour difference from most toast defaults, and it interacts with closeOnClick, which defaults to true. max defaults to Infinity, so nothing is dropped unless you set it.

Install and a first notification

The README's setup is three steps. Install from npm, register the plugin in main.js, and place the component once in App.vue.

npm install --save vue-notification

In main.js, import Vue and the plugin and call Vue.use. The README notes that SSR builds should import from vue-notification/dist/ssr.js instead of the package root.

import Vue from 'vue'
import Notifications from 'vue-notification'

Vue.use(Notifications)

Then add the holder to App.vue. All props are optional, so a bare tag works and defaults to position top right with a 300 px width.

<notifications/>

Triggering from a component is one call. The title is wrapped in div.notification-title and the text in div.notification-content, which is where you hook your CSS.

this.$notify({
  title: 'Important message',
  text: 'Hello user!'
})

If you need a second holder, add another component tag with a group and a position, then pass the same group in the call. The README's example is group="auth" with position="top" alongside group="app" with position="bottom right". The position string always takes two keywords, vertical then horizontal, drawn from top or bottom and left, center or right.

Where the design gets in the way

The peer dependency is vue ^2.0.0. There is no Vue 3 support in the package metadata, and the searches for vue3-notification point at a different project. If you are migrating a codebase to Vue 3, this plugin is a migration item, not a dependency you keep.

The animation story is thinner than the prop table suggests. animation-type supports css and velocity, and the README says animation-name is required when the type is css, while the velocity path takes an animation object. Nothing in the README documents a default animation, so a bare <notifications/> with no animation-name is a configuration you should check against your own build rather than assume.

Styling is entirely yours. The library adds classes (vue-notification by default, plus whatever you pass in classes, plus the type string) and leaves the appearance to your stylesheet. That is a reasonable boundary, but it means the package gives you no visual starting point.

SSR has a documented sharp edge. The README warns that setting componentName can cause issues when using SSR, and the Nuxt section splits the plugin into two files, one with ssr: true importing dist/ssr.js and one with ssr: false importing the default build. If you rename the component, you are in undocumented territory.

vue-notification against vue-toastification and vue3-notification

The searches around this project name vue-toastification, vue3-notification, Vue hot-toast and Vue toast, and the choice between them is mostly a choice about how notifications are triggered.

vue-notification's model is a prototype method plus a global component. There is no composable to import and no store to configure; the plugin mutates the Vue constructor once and every call site uses this.$notify. Groups are declared by placing additional component tags, so the set of holders is visible in App.vue.

A Vue 3 toast library such as vue3-notification targets a different major version of the framework, which is the deciding factor before any feature comparison matters. vue-toastification, as the name suggests, is also positioned around toasts; the README here does not compare itself to either package, so treat any feature-level comparison as something you verify against their own documentation rather than this one.

The practical difference is scope. vue-notification gives you a holder component, an API, groups, and a class hook. Anything beyond that (queueing policy, deduplication heuristics, theming) is either a prop like max or ignoreDuplicates or your own code.

Maintenance, versioning and the MIT licence

The repository last received a push on 2026-09-26, and it is not archived. The most recent published release listed is 1.3.16 from 2019-02-09, while package.json in the repository declares version 1.3.20. That gap between the release list and the manifest is worth knowing before you pin a version: check the npm registry for what is actually published rather than assuming the manifest is what you will install.

The licence is MIT, declared in both the repository and package.json. MIT permits commercial and closed-source use with the copyright notice retained; that is the general shape of the licence, not legal advice for your situation.

The upgrade cost is bounded by the peer dependency. Because the plugin targets Vue 2, the largest upgrade event in its future is the one you control: moving the host application to Vue 3, at which point the plugin is replaced rather than upgraded. Within Vue 2, the API surface is small enough that a version bump is unlikely to be the expensive part of your week. The build scripts in package.json run webpack twice, once for the base bundle and once for the SSR bundle, which is why the dist/ssr.js import path exists.

Editorial conclusion

Adopt vue-notification if your app is on Vue 2 (peer dependency vue ^2.0.0) and you want notifications triggered from anywhere via this.$notify or Vue.notify, with per-group holders and a CSS or Velocity animation layer. Do not adopt it for a Vue 3 codebase: the peer dependency is ^2.0.0, and the searches pointing at vue3-notification describe a different package. Before wiring it in, verify the group names you plan to use, the position string format of two keywords, and whether your bundler resolves dist/ssr.js through the Nuxt plugin split shown in the README.

Frequently asked questions

Official sources

1. euvl/vue-notification on GitHub
2. License: MIT
3. Project website
4. README
5. Releases