# iNotify is a 5kb dependency-free browser notification library

> iNotify is a small JavaScript library that makes a browser tab draw attention by flashing and scrolling the page title, playing a voice prompt, and firing a desktop notice, in Chrome, Safari, Firefox and IE. It ships with no dependencies, weighs 5.05kb gzipped to 1.75kb, and is distributed as CommonJS, ESM and a browser global, so it can be dropped into a page that already has a framework.

**jaywcjlove/iNotify** — :loudspeaker: JS achieve the browser title flashing, scrolling, voice prompts, Chrome/Safari/FireFox/IE notice. has no dependencies. It not interfere with any JavaScript libraries or frameworks. has a reasonable footprint 5.05kb (gzipped: 1.75kb)

- Repository: https://github.com/jaywcjlove/iNotify
- Website: https://git.io/iNotify
- Stars: 1,047 · Forks: 178
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/jaywcjlove-inotify

## Four ways to pull attention back to a tab

The library description is the clearest statement of what it does. JS achieve the browser title flashing, scrolling, voice prompts, Chrome/Safari/FireFox/IE notice.

Each of those four is a different way of saying the same thing to a user who has looked away from the tab. The title flash is the classic: the tab label alternates with something else so it catches the eye in a row of tabs. The scrolling variant takes the same idea and moves the text through the title bar, which is harder to miss but also harder to read, so it suits an alert that is meant to be noticed rather than read. A voice prompt plays a spoken message, which is the option that works when the user is not looking at the screen at all, and it depends on whatever speech facility the operating system provides. The notice is the standard desktop notification, with the browser's own permission prompt in front of it.

The coverage of browsers is worth noting because it is old-fashioned. Chrome, Safari, Firefox and IE are all named, and the IE mention is a signal about the project's vintage and about the author's intent, which is to support the notification APIs of that era rather than to target only the modern ones.

One point of caution for a reader. The repository's README opens with a banner of links to the author's commercial macOS applications. The demo page is where the options and the title behaviour are actually shown.

For a library this small, letting the demo stand in for a written specification is a normal arrangement.

## No dependencies and no interference are the design constraints

The description lists two constraints that explain the shape of the library better than any feature list would.

The first is has no dependencies. There is no runtime dependency in the package.json, whose dependencies object is absent entirely, and the only packages listed are devDependencies for the build and the documentation site. For a library whose job is to touch the document title and the Notification API, a dependency tree would be disproportionate, so writing it standalone is the obvious choice, but stating it as a headline feature tells you the author expects people to compare it on that basis.

The second is it not interfere with any JavaScript libraries or frameworks. This is the constraint that shapes the implementation more than anything else. A title-flashing library has to take over document.title, which means it has to save the original value, replace it, and put it back. If it does that badly, it fights with whatever else in the page is writing to the title, and with routers or frameworks that manage the document themselves.

The third constraint is size. The description gives a reasonable footprint of 5.05kb, gzipped 1.75kb. For a library whose entire job is to change a string in the tab bar, that is a defensible budget, and it is quoted in the description precisely because it is small enough to be checked against a bundle budget at a glance.

Together these three constraints define the audience: a web developer who needs a tab notification in a page that already has React, Vue or something else, and who cannot add a dependency tree to a project with a bundle budget. That is a narrow but real niche, and the library fits it.

## Rollup produces the CommonJS, ESM and browser builds

The package.json shows the distribution, and it is a careful one.

The package is @wcjiang/notify at version 2.1.4, with the main entry at index.js, an ES module build at dist/notify.esm.js and an unpkg entry at dist/notify.js, which is the file served to a script tag. The dist/ directory is checked into the repository, which is the normal arrangement for a package that wants the unpkg path to work without a build step on the consumer's side.

The build itself is Rollup.

```json
"build": "rollup -c rollup.config.mjs",
"watch": "rollup -c rollup.config.mjs -w"
```

The Rollup plugin list is short and says something about the priorities. There is the commonjs plugin, the json plugin, the node resolver and the terser plugin for minification, and rollup-plugin-sizes, which prints the size of each generated bundle. That last one is the tool you would expect in a project that quotes its footprint in the README, because the number in the description is a build output rather than a claim.

The browserslist configuration is the other place where the priorities show. The production target is greater than 0.2%, not dead and not op_mini all, which is a conservative, compatibility-first list, and the development target is the last version of Chrome, Firefox and Safari. Naming IE in the feature description and targeting a conservative browser set in the build are the same decision taken twice.

The build outputs are also where the three sizes come from. The description quotes 5.05kb for the package and 1.75kb gzipped, and the plugin-sizes setup is what keeps that number honest on every release.

## The documentation site is a React app built with kkt

The website/ directory at the root of the repository is the project's documentation and demo, and the tooling for it is unusual enough to be worth naming.

The scripts in package.json use kkt, the author's own build tool, with start running kkt start --app-src./website to serve the site locally and doc running kkt build --app-src./website to build it. The devDependencies show the stack that site is built with: React and React DOM at 18.2, @uiw/react-markdown-preview to render the Markdown documentation, @wcj/dark-mode for the theme switch, @uiw/react-github-corners for the corner links, bannerjs for the announcement banner, and classnames for class name composition.

That the documentation site is a React application built with the author's own framework is a design choice with consequences. It means the demo is interactive in a way a static page cannot be, and the reader can change options and see the title flash live rather than reading about it. It also means the site is a consumer of the library, in a sense, since it is the same code path a user would take.

The kkt configuration lives in the.kktrc.js file at the root, and the less-modules and raw-modules plugins are declared alongside the framework packages.

For a reader deciding whether to use the library, the practical instruction is short: the demo page is at jaywcjlove.github.io/iNotify, and the README's preview image points at it. That page is the reference for the options.

## MIT in the package, a custom licence in the repository metadata

There is a licensing inconsistency worth naming, because it is the kind of thing that stalls a compliance review.

The package.json declares the licence as MIT, and the repository contains a file named MIT-LICENSE at the top level, which is consistent with each other. The repository metadata, on the other hand, reports the licence as a custom licence that GitHub cannot classify, pointing at the LICENSE file. There is no file named LICENSE among the top-level entries, which is.editorconfig,.github/,.gitignore,.kktrc.js,.npmignore, MIT-LICENSE, README-zh.md, README.md, dist/, index.js, package.json, public/, renovate.json, rollup.config.mjs, src/, test/ and website/.

So the machine-readable metadata that npm and most scanners read says custom and unknown, while the package and the file in the tree say MIT. The likely explanation is that the file was renamed to MIT-LICENSE at some point and the repository metadata was never updated, but the result for an adopter is that an automated licence check will not produce the answer you expect and a human has to resolve it.

Under the terms stated in the package and in MIT-LICENSE, the code is MIT licensed: use, modification and redistribution are fine, including commercially, provided the copyright notice and the licence text are kept. That is a licensing fact rather than legal advice, and for a dependency-free browser library with no server component it is a low-risk situation, provided someone confirms the file is the licence you expect.

The README also carries the author's commercial macOS applications and a note that using the app is a way to support him, which is the funding model rather than a licence term, but it does tell you who maintains the project and what they do for a living.

## A two-year gap between releases, and a repository still being touched

The release history is the main signal about the project's rhythm. The recent releases are v2.1.4 on 2025-10-11, v2.1.3 on 2023-11-26 and v2.1.2 on 2023-11-26, so two releases landed on the same day two years before the latest one.

The repository is not archived, the default branch is master, and the last push was on 2026-04-21. The commits continue, and the release tags are sporadic.

That pattern is typical of a small utility library whose author maintains a large set of projects. A library that does one thing, has no dependencies and whose main risk is bit rot from browser changes does not need a release every few weeks, and the dependency updater configuration in the repository, renovate.json, is the mechanism that keeps the build current when it does need attention.

The test/ directory at the root is worth noting for anyone planning to contribute, and the .github/ directory holds the workflows. There is also a Chinese README at README-zh.md and a link to it at the top of the English one, which is a small signal about where the project's users are.

For an adopter, the practical consequences are modest. The API surface is small, the package has no dependencies to conflict with, and the last release is recent enough that the browser targets are current. What you do not get is a stream of releases to watch, so the changelog, rather than the release feed, is where you look for what changed.

## Conclusion

iNotify fits a project that needs to pull a user's attention back to a tab without a full notification stack, and that cannot take a dependency or fight with the framework already on the page. It does not fit a team that needs a specification-complete notification system, and voice prompts depend on what the operating system can synthesise. Before adopting it, read the demo at jaywcjlove.github.io/iNotify to see the four behaviours in the browser, check that the 5.05kb cost is acceptable next to your existing bundle, and confirm that the MIT-LICENSE file in the repository matches the licence your compliance tooling reads from the package metadata.

## FAQ

### What does the iNotify JavaScript library do?

It makes a browser tab draw attention in four ways: flashing the page title, scrolling it, playing a voice prompt, and showing a desktop notice, with support described for Chrome, Safari, Firefox and IE. It is distributed as @wcjiang/notify and has no dependencies.

### How big is iNotify and does it slow a page down?

The project describes a reasonable footprint of 5.05kb, gzipped to 1.75kb, and the build uses rollup-plugin-sizes to print bundle sizes. The package has no runtime dependencies, and the stated design goal is that it does not interfere with any JavaScript libraries or frameworks.

### How is iNotify packaged and built?

The package uses Rollup with a configuration in rollup.config.mjs, and the build script is rollup -c rollup.config.mjs. The published entry points are index.js for CommonJS, dist/notify.esm.js for ES modules and dist/notify.js for the unpkg browser build, with dist/ checked into the repository.

### What licence does iNotify use?

The package.json declares the licence as MIT and the repository contains an MIT-LICENSE file, although the repository metadata reports a custom licence that GitHub cannot classify. The documentation site is hosted at jaywcjlove.github.io/iNotify and also serves the demo.

### Is iNotify still being updated?

The repository is not archived and the last push was on 2026-04-21. The most recent release is v2.1.4 from 2025-10-11, with v2.1.3 and v2.1.2 both published on 2023-11-26, and dependency updates are handled through the renovate.json configuration in the repository.

## Sources

- [Issues](https://github.com/jaywcjlove/iNotify/issues)
- [jaywcjlove/iNotify on GitHub](https://github.com/jaywcjlove/iNotify)
- [Project website](https://git.io/iNotify)
- [README](https://github.com/jaywcjlove/iNotify/blob/master/README.md)
- [Releases](https://github.com/jaywcjlove/iNotify/releases)

---

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