Notiflix: a zero dependency notification library the author calls legacy

The project says outright that it is legacy

The most useful thing in this repository is the notice at the top of the readme, and it is worth reading before anything else.

The project is under maintenance and LTS mode. Notiflix was built in the era of Internet Explorer, Twitter and Bootstrap, FontAwesome and the rest, and just as that era is over, Notiflix has also become legacy and does not meet modern web technology standards or mandatory accessibility regulations.

The author then says what it is still good for. The library will still work as long as web browsers support JavaScript, and it can still be useful for backoffice and admin panels, personal or demo projects, or internal tools. For business critical applications, the advice is to consider modern alternatives or to build your own implementation.

That is an unusual thing for a library to say about itself, and it changes how you should read everything else in the repository. The feature list is not a roadmap. The version history is not a sign of activity.

What the notice also tells you is that the library is not abandoned in the sense of being broken. It will still run in a current browser. The problem is the standard it meets and the accessibility rules it does not, which for a customer facing product is a real problem and for an internal tool is usually not.

The primary language is JavaScript, the licence is MIT, the default branch is main, and the last push to the repository was on 2026-10-19. The homepage is notiflix.github.io and the documentation lives at notiflix.github.io/documentation.

Five modules, and a different one for each kind of interruption

The library offers client-side non-blocking notifications, popup boxes, loading indicators and more, and the five modules map onto five different kinds of interruption.

Notify is the toast, for non-blocking alerts, and it has four types: Success, Failure, Warning and Info. Report is the extended notification, which contains a title, a description and a button with a callback function, and it has the same four types. Confirm is the yes or no dialog. Loading is the loading indicator. Block is the element that blocks the page and the interaction with it.

Each has its own playground page, Notify, Report, Confirm, Loading and Block, which is the fastest way to see what a module actually does before you write the integration.

The calling convention is uniform across the modules, and the parameter documentation for Notify shows the pattern. The first parameter is a required string of text. The second is optional and is either a callback function called when the notification element is clicked, or an object extending the initialize options with new options for that element. The third is optional and is that options object, and it is only usable when the second parameter has not been used for a callback.

So the three shapes are a message alone, a message with a callback, a message with options, and a message with both a callback and options. Every module follows the same convention, which means once you know it for one you know it for all five, and the code is easy to read even though the library is old.

The build is a script tag, and that is a deliberate choice

Notiflix can be used the way the libraries of its era were used, which is worth understanding because it is also the thing that makes the project awkward to adopt into a modern bundler setup.

The package is installed as any other npm package:

npm i notiflix

or with yarn add notiflix. And it can be imported either as everything at once or one module at a time:

// all modules
import Notiflix from 'notiflix';

// one by one
import { Notify } from 'notiflix/build/notiflix-notify-aio';
import { Report } from 'notiflix/build/notiflix-report-aio';
import { Confirm } from 'notiflix/build/notiflix-confirm-aio';
import { Loading } from 'notiflix/build/notiflix-loading-aio';
import { Block } from 'notiflix/build/notiflix-block-aio';

The main entry in package.json is dist/notiflix-aio-3.2.8.min.js, so a plain import pulls the all-in-one build, and the per-module paths are there for a bundler that wants to tree shake.

The script tag route is the other half. You can link the stylesheet and the script directly:

<link rel="stylesheet" href="dist/notiflix-3.2.8.min.css" />

<script src="dist/notiflix-3.2.8.min.js"></script>

Or you can take the all-in-one build with its CSS inside it, either as one file or as one file per module:

<script src="dist/notiflix-aio-3.2.8.min.js"></script>

The fact that the version number is baked into the file names, 3.2.8 throughout, is a small sign of the era. It also means a CDN url has to change on every upgrade, which is exactly the pattern that later moved to unversioned or hashed assets.

The Notify signature, and the four call shapes

The Notify module is documented in enough detail to be a good template for the other four, because the parameter convention is identical.

The simplest call is a message with a type:

// e.g. Only message
Notiflix.Notify.success('Sol lucet omnibus');

Notiflix.Notify.failure('Qui timide rogat docet negare');

Notiflix.Notify.warning('Memento te hominem esse');

Notiflix.Notify.info('Cogito ergo sum');

Then a message with a callback, where the callback fires when the notification element is clicked:

// e.g. Message with a callback
Notiflix.Notify.success(
  'Click Me',
  function cb() {
    // callback
  },
);

Then a message with options, where the options object extends the initialize options with the new options for that element, in this case a timeout:

// e.g. Message with the new options
Notiflix.Notify.success(
  'Click Me',
  {
    timeout: 6000,
  },
);

And then both together, with the callback in the second position and the options in the third:

// e.g. Message with callback, and the new options
Notiflix.Notify.success(
  'Click Me',
  function cb() {
    // callback
  },
  {
    timeout: 4000,
  },
);

The Report module follows the same shape with one extra required parameter, since it carries a title, a message and a button text, and the button carries the callback:

// e.g. Only title, message, and button text
Notiflix.Report.success('Title', 'Message', 'Button Text');

Notiflix.Report.failure('Title', 'Message', 'Button Text');

Notiflix.Report.warning('Title', 'Message', 'Button Text');

Notiflix.Report.info('Title', 'Message', 'Button Text');

The Latin phrases in the examples are a small piece of the project's character, and they are also a useful signal about the audience it was written for.

Zero dependencies, TypeScript types, and a very old toolchain

The claim in the project description is dependency-free, secure and lightweight, built with pure JavaScript. Looking at the manifest, the first part is verifiable: there is no dependencies block at all in the package.json. Everything the library needs is bundled into the dist/ and build/ output.

The TypeScript claim is also checkable. The package ships index.d.ts as its types entry, and there is an index.d.test.ts alongside it, which is a type-level test rather than a runtime one, so the declarations are verified by the compiler rather than by a browser. The badge in the readme points at the same file.

The devDependencies tell you the era more precisely than the version number does. The Babel toolchain is @babel/core, @babel/preset-env and @babel/preset-typescript at 7.16, with babel-jest and babel-minify. The test runner is jest 27 with puppeteer-core 11, and the type definitions include @types/puppeteer, which is how the library tests its own DOM behaviour in a real browser. The linters are eslint 7 with the TypeScript plugin at 4, stylelint 13 with the standard config, and TypeScript 4.4.

So the build is Babel plus Jest plus Puppeteer plus stylelint, all from 2021. That is not a criticism of the output, it is an explanation of what the maintenance mode means: the toolchain still works, but it is not being upgraded, and the browsers it was verified against are older than the ones your users have.

The repository layout matches a conventional front-end library: src/ for the sources, build/ and dist/ for the compiled output, which is both committed and published, test/ for the Jest and Puppeteer suites, docs/ for the documentation site, a .dev/ directory, and the configuration files, jest.config.js, babel.config.js, tsconfig.json, .eslintrc.json and .stylelintrc.json. There is a CNAME file, a SECURITY.md, and a CODE_OF_CONDUCT.md.

Where Notiflix is the wrong tool

The first limit is the one the author states, and it is not a small one. The library does not meet modern web technology standards or mandatory accessibility regulations, and a toast that appears on screen is exactly the kind of component where an accessibility rule bites, because a notification that only exists visually and disappears on a timer is invisible to a screen reader user and to anyone who cannot perceive the visual cue in time. For a customer facing product that is disqualifying, and the project says so.

The second is the maintenance mode itself. The last release is v3.2.8 from 2025-01-04, before it v3.2.7 from 2024-01-02 and v3.2.6 from 2023-01-11, which is a steady one release a year pattern, and the last push to the repository was on 2026-10-19. The recent push is worth noting on its own, because it shows the code is not frozen, but the release line is where a consumer of the package is affected, and there has been no new release since January 2025.

The third is the absence of a modern integration story. The package has no dependencies and no framework bindings, so it works in a React, Vue or Angular application, and the topic list names react-notifications, angular-notification and nextjs-notifications as use cases. But the imports point at paths under build/, and the shipped entry point is a prebuilt minified bundle with the version in the filename. A project with a strict Content Security Policy, a strict bundle size budget, or a policy of no prebuilt vendor code in node_modules will have work to do here, and the scripts are served from dist/ with their own CSS in a separate file unless you take the all-in-one build.

The fourth is that the library is a UI kit, not a notification service. It draws toasts, it does not deliver them, and a client-side toast does not survive a page navigation, a tab being closed, or a user who is not looking at the screen. If the thing you need is a message that reaches the user, a Web Notification or a push channel is the mechanism, and Notiflix is a decoration in front of it.

The fifth is the alternative the project itself points at, and it is a reasonable one. For a business critical application the guidance is to consider modern alternatives or to build your own implementation, and the cost of that path is a few hundred lines of DOM work for a toast and a confirm dialog, which is what most teams end up doing anyway.

Editorial conclusion

Notiflix is worth using for a backoffice, an admin panel, a demo or an internal tool where a toast and a confirm box are all you need, because it has no runtime dependencies, ships TypeScript definitions, and gives you five modules in a few kilobytes of JavaScript that you can drop on a page as a script tag. It is the wrong choice for anything customer facing, and the project says so itself. Before you adopt it, check the three things the project states about itself: that it is under maintenance and LTS mode and does not meet modern web technology standards or mandatory accessibility regulations, which means a new feature request is not going to be answered; that the current version is 3.2.8 from 2025-01-04, so the library is stable but not gaining capability; and that the package still ships an all-in-one bundle and per-module builds, so you can control how much of it ends up in your page.

Frequently asked questions

Official sources

1. License: MIT
2. notiflix/Notiflix on GitHub
3. Project website
4. README
5. Releases