# vue-notification: one release from 2019, a manifest at 1.3.20, and two bundles to import

> A Vue 2 notification library whose package manifest, tag list and build scripts disagree in useful ways: SSR needs a second entry point by path, the test stack still launches PhantomJS, and the shipped dist directory sits in the tree next to a demo with two lock files.

**euvl/vue-notification** — :icecream: Vue.js 2 library for showing notifications

- Repository: https://github.com/euvl/vue-notification
- Website: http://vue-notification.yev.io/
- Stars: 2,378 · Forks: 203
- Language: JavaScript
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/euvl-vue-notification

## The manifest is at 1.3.20 and the only listed release is from 2019

Installation is one command:

```bash
npm install --save vue-notification
```

Two version numbers then describe this package and they do not match. The package manifest declares version 1.3.20, while the release list holds a single entry, 1.3.16, dated 2019-02-09. The last recorded push is dated 2026-10-02, so commits have landed long after that tag without a second release appearing in the list. For anyone installing from npm the manifest is the number that appears, and for anyone pinning a git tag the number is 1.3.16. There is no changelog in the tree to explain the difference, no tags to compare, and no build that publishes a version, since the two build scripts in the manifest only run webpack and produce local bundles. The gap is a packaging fact rather than a code fact: the source tree has moved on, and the release list has not.

## Server side rendering needs a second entry imported by path

The library ships two bundles and the package entry points at only one of them. The manifest main field is dist/index.js, while the setup section notes an alternative import for SSR, vue-notification/dist/ssr.js, commented as or for SSR. Two webpack configs produce them, webpack.config.js and webpack.config.ssr.js, and the build script runs the base build and then the SSR build in sequence, so a publish has to include both. The Nuxt.js section shows why the split matters: nuxt.config.js registers two plugins, one with ssr: true pointing at a file that imports the dist/ssr.js path and one with ssr: false pointing at a file that imports the package normally. A second warning sits in the plugin options table, that setting componentName can cause issues when using SSR.

## Twelve props, and duration inverts its own default

Most behaviour is set through props on the global component, and all twelve are optional. position defaults to top right, width to 300, classes to vue-notification, group to null, duration to 3000, speed to 300, animation-type to css, animation-name to null, animation to a custom object, max to Infinity, reverse to false, ignoreDuplicates to false and closeOnClick to true. The one worth reading twice is duration, where a negative value means the notification stays forever or until clicked, which inverts the usual meaning of the number. Two others have defaults that hide their cost: max is Infinity, so a group will hold as many notifications as the caller fires, and ignoreDuplicates defaults to false, so identical notifications stack unless told otherwise.

## The test scripts still launch Karma against PhantomJS

The test side of the manifest describes a browser testing stack from an earlier era. unit runs karma start test/unit/setup/karma.conf.js with BABEL_ENV=test and a single run flag, unit:watch adds watch, and test is npm run unit. The dev dependencies match that shape: karma 1.7 with karma-mocha, karma-sinon-chai, karma-coverage, karma-spec-reporter, karma-webpack, karma-sourcemap-loader, a karma-phantomjs-launcher, a karma-phantomjs-shim and avoriaz with chai and sinon behind it. The build side is the same vintage, with webpack configured through two files and run with the --hide-modules flag, babel-core 6 with the env, latest and stage-2 presets, css-loader at 0.25 and file-loader at 0.9. The project pushes commits, but the harness it carries was assembled for a browser that npm packages stopped shipping years earlier.

## position takes two keywords and the README misspells its own term

The position prop is the one with a format contract. It requires a string with two keywords, one vertical and one horizontal, in the order <vertical> <horizontal>. The horizontal options are left, center and right, the vertical options are top and bottom, and the default is top right. The description sentence that states the rule spells the second half of the word as postion, which is the only place in the documentation that the term appears misspelled and worth knowing if you are searching the source for the property name. The width prop is looser and takes four forms in one place: a bound number as :width="100", an unquoted number as width="100", a percentage as width="100%", and a pixel string as width="100px".

## Removal happens through clean, and a group scopes it

Triggering goes through this.$notify, which accepts a bare string or an options object. The object keys do four jobs. title and text are wrapped, in div.notification-title and div.notification-content respectively, and both accept markup, with the title example carrying an em tag and the text example a b tag. type is added as a CSS class name to the .vue-notification element, which is how the styling hook works, since styling is done by passing your own class names through the classes prop. duration and speed override the component defaults for that one message. Removal is a single flag, clean: true, and adding a group to the same call limits the clean to that group, so group: foo with clean: true clears only the foo holder.

## Groups are separate components with separate positions

There is no routing layer inside the library. A group is simply the group attribute on one notifications component, and to have two kinds of message on screen you mount two of them, as the documentation shows with an auth group at position top and an app group at position bottom right. The caller then picks the destination by passing group in the notify call. The related plugin option is name, which defaults to notify and is prefixed with a dollar sign, so the method is $notify by default and becomes something else if the plugin is registered as Vue.use(notifications, { name: 'alert' }). That registration example also spells the plugin in lowercase where the setup section imports it as Notifications, a small inconsistency that matters only if you rely on the exact identifier.

## dist is committed and the demo carries two lock files

The build output lives in the repository. dist/ is a top level entry, and the manifest main field points into it, so the compiled bundle that consumers load is committed rather than produced at install time. There is also an .npmignore, which is the file that decides what gets left out of the published tarball, and a yarn.lock at the root while the scripts themselves are written with npm run. The demo/ directory is a separate application: it has its own package.json, its own webpack.config.js and its own .babelrc, and it carries both a yarn.lock and a package-lock.json in the same directory. index.d.ts sits at the root and is wired up through the types field, so TypeScript declarations are shipped alongside the bundles.

## Conclusion

Reach for vue-notification when you are on Vue 2 and want notifications with groups, per group positioning and a class hook for styling, and when you can live with a dependency whose published build was cut by an older toolchain. Check three things before adopting it. If you render on the server, import vue-notification/dist/ssr.js rather than the package entry, and do not rename the component, since the docs warn that componentName can cause issues under SSR. If you pin a version, note that the manifest is at 1.3.20 while the only listed release is 1.3.16 from 2019-02-09, so a tag and an installed version will not line up. And if you run its own test suite, the launcher is Karma with PhantomJS, so expect to rework it before trusting it.

## FAQ

### Which Vue versions does vue-notification support?

It is a Vue.js 2 library, and the peer dependency is declared as vue ^2.0.0.

### How do I install and register vue-notification?

Run npm install --save vue-notification, import it in main.js, register it with Vue.use(Notifications), and add the notifications component to App.vue. Notifications are then fired with this.$notify.

### How do I keep a vue-notification message on screen indefinitely?

Set duration to a negative number. A negative duration keeps the notification forever or until it is clicked, where the default value is 3000 milliseconds.

### How do I use vue-notification with Nuxt.js and server side rendering?

Register two plugins in nuxt.config.js: one with ssr: true importing vue-notification/dist/ssr.js and one with ssr: false importing the default entry. The documentation also warns that setting componentName can cause issues when using SSR.

### How do I remove notifications from vue-notification?

Pass clean: true in the notify call. Adding a group property limits the clean to that group, so group: foo with clean: true clears only the foo holder.

### Which version of vue-notification is current?

The package manifest declares 1.3.20, while the only listed release is 1.3.16 dated 2019-02-09. The last recorded push is dated 2026-10-02, so the source has moved on from that tag.

## Sources

- [euvl/vue-notification on GitHub](https://github.com/euvl/vue-notification)
- [License: MIT](https://github.com/euvl/vue-notification/blob/master/LICENSE)
- [Project website](http://vue-notification.yev.io/)
- [README](https://github.com/euvl/vue-notification/blob/master/README.md)
- [Releases](https://github.com/euvl/vue-notification/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/euvl-vue-notification