# notistack's npm test script is echo todo-test, and v3 dropped the Material-UI dependency

> notistack is a React snackbar library whose whole surface is one provider, one enqueue function and one hook. The details that decide whether to adopt it are in the manifest: three version families with different peer dependency needs, a flat set of entry points from a tsdx build, peer ranges that cover React 19 while development happens on 18, and a test script that does nothing.

**iamhosseindhv/notistack** — Highly customizable notification snackbars (toasts) that can be stacked on top of each other

- Repository: https://github.com/iamhosseindhv/notistack
- Website: https://notistack.com
- Stars: 4,077 · Forks: 293
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/iamhosseindhv-notistack

## Two install commands and three version families

The getting started section is two lines, one for npm and one for yarn, both installing the same package:

```
npm install notistack
yarn add notistack
```

What follows is a version guide, and it is the part that decides your install command. The `v3.x.x` line is described as the latest stable release and as standalone, meaning it does not depend on Material-UI. Anything at or below `v2.0.8` requires Material-UI v5 as a peer dependency and is installed as `notistack@2.0.8`. Anything at or below `1.0.10` requires Material-UI v4 or lower as a peer dependency and is installed through a separate tag, `notistack@latest-mui-v4`.

So a project upgrading from either legacy line changes not only its version number but the dependency graph around it, which is the part an upgrade note should call out and a version table can leave implicit.

## v3 removed Material-UI, and the older lines keep it

The standalone claim is the substantive change in v3. The previous design was built on Material-UI, which made sense when snackbars were one more component in a Material design system and awkward when they were not: a project using another component library still had to install Material-UI for notifications.

The cost of that change is visible in the version table rather than in prose. Two installation paths exist purely for compatibility, one pinned to an exact version, `notistack@2.0.8`, and one behind a dist tag for the Material-UI v4 era. Both remain documented, which is generous, and both mean a codebase can end up with a snackbar version selected by a tag nobody remembers writing.

## The API is one provider, one function and one hook

Notifications are displayed by calling a function, and the example shows the whole arrangement: import `SnackbarProvider` and `enqueueSnackbar`, render the provider once, and call the function from an event handler.

```jsx
import { SnackbarProvider, enqueueSnackbar } from 'notistack';

const App = () => {
  return (
    <div>
      <SnackbarProvider />
      <button onClick={() => enqueueSnackbar('That was easy!')}>Show snackbar</button>
    </div>
  );
};
```

There is a hook form for components that want to close what they opened, `useSnackbar`, which returns `enqueueSnackbar` and `closeSnackbar`. It only works inside the provider's context, so the application has to be wrapped in `SnackbarProvider`, which is the single structural requirement the README states. Everything else, the full list of props, lives in the documentation site's API reference.

## The test script prints a placeholder and exits

The manifest has a script called `test` whose entire body is `echo todo-test`. Whatever else the repository does during a release, the test command does not run a test. That single line is the clearest maturity signal in the package, and it is worth weighing against the feature list, because a notification library's hard cases are timing and stacking rather than types.

The rest of the script list is a conventional release pipeline. `prebuild` runs the docs script, `build` runs tsdx against `src/index.ts`, `docs` deletes `typedoc.json` and regenerates it with typedoc, and a `copy` script copies `package.json`, `README.md` and `LICENSE.md` into `dist`. Publishing goes through `npm run prerelease` and then `np` with the latest tag, and `postversion` runs the copy step again.

## Flat entry points from a tsdx build, not an exports map

The entry points are three flat names: `main` points at `./index.js`, `module` at `./notistack.esm.js` and `types` at `./index.d.ts`. There is no exports map in the visible part of the manifest, so resolution is left to `main` and `module`, which is the shape tsdx has always produced.

The build tool matches. The repository carries `tsdx.config.js` and a `.babelrc` at the root, the build is `tsdx build --entry ./src/index.ts`, and watch mode adds `--transpileOnly`. Publishing is then a file copy rather than a pack from source, so the package root of the published artefact is assembled by the copy script mentioned earlier. None of this is broken, but it is the build setup of an earlier era of the ecosystem, and it is the kind of thing to look at before a bundler-level upgrade.

## Peer range covers React 19, the dev toolchain is on React 18

The peer dependencies accept React and React DOM at `^17.0.0 || ^18.0.0 || ^19.0.0`, so a consumer on any of those majors can install it. Inside the repository the development versions are React and React DOM at `^18.1.0`, which is the gap worth noting: the supported range is wider than the range the library is built and demonstrated against.

The surrounding tooling is also a generation behind, though each tool is a choice rather than a problem. ESLint is pinned at `^7.7.0` and Prettier at `^2.7.1`, with the typescript-eslint packages at `^5.28.0` and eslint-plugin-react at `^7.30.0`. Babel is there with the React preset and a plugin for optimising class name strings. Nothing about that prevents use, and all of it predicts friction if you open a pull request against a repository whose lint stack predates your own.

## No GitHub releases, a March commit date, and a one sentence contribution policy

The repository publishes no GitHub releases, so the version history lives in `CHANGELOG.md` at the root rather than in a tag list, and the most recent commit is dated 31 March 2026. The project is not archived, and the manifest sits at 3.0.2, so the version in the file matches the stable line the README describes.

What the README does not mention is `MIGRATION.md`, which sits beside it and is the obvious place to look for how to move between the three version families. The contribution section is a single sentence inviting issues, which tells you that pull request review is not the path the maintainer expects people to take, and the repository carries an `examples/` directory whose seven projects include MobX and Redux integrations that appear nowhere in the documentation.

## Seven example projects, and none of them is in the README

The examples directory holds `simple-example`, `custom-snackbar-example`, `custom-snackbar-example-2`, `custom-content-example`, `mobx-example` and `redux-example`, plus its own `.eslintrc`. Only the simple example is referenced in the README, through a CodeSandbox link, and the rest of the examples are left for a reader to discover.

That is the more interesting half of the list. A MobX example and a Redux example say something about how the library is meant to sit in an application that manages state elsewhere, and a project that wants to queue notifications from a store has a reference for it here even though the documentation site does not mention either. The two custom snackbar examples and the custom content example cover the customization half of the description, which is the half a design system team will actually use.

## Conclusion

notistack is a good fit if you want snackbars with stacked and queued behaviour and you are on the current line, since v3 is standalone and no longer asks you to install Material-UI alongside it. Before you pin a version, decide which family you are on, because the install command differs per line and the two older lines carry a peer dependency on Material-UI that v3 removed. Treat the maturity signals for what they are: the manifest's test script does nothing, the build still runs through tsdx with flat entry points rather than an exports map, and the last commit is dated 31 March 2026 with no GitHub releases to check it against. If snackbars are a small part of your product, that is a thin dependency to own; if the behaviour is central, read the documentation site's prop list before you rely on the defaults.

## FAQ

### How do I use notistack?

Wrap your app once in SnackbarProvider, then call enqueueSnackbar from anywhere, passing a message string. Components that need to dismiss what they opened can use the useSnackbar hook instead, which returns enqueueSnackbar and closeSnackbar and only works inside the provider's context. The full prop list is in the API reference on the documentation site.

### Does notistack still need Material-UI?

Not on the current line. Version 3.x is described as standalone, meaning it does not depend on Material-UI. Releases up to v2.0.8 require Material-UI v5 as a peer dependency and are installed as notistack@2.0.8, and anything up to 1.0.10 requires Material-UI v4 or lower through the latest-mui-v4 tag.

### How do I install notistack, and which version should I take?

With npm install notistack or yarn add notistack. The version guide separates three families: v3.x.x as the latest stable and standalone, releases up to v2.0.8 which need Material-UI v5 as a peer dependency, and releases up to 1.0.10 which need Material-UI v4 or lower and are installed under a separate tag.

### Which React versions does notistack support?

The peer dependencies accept React and React DOM at ^17.0.0, ^18.0.0 or ^19.0.0. The versions used inside the repository for development are React and React DOM at ^18.1.0, so the declared support range is wider than the one the library is built against.

### How does notistack compare with sonner?

The repository makes no comparison with sonner or any other notification library. What it states about itself is that v3.x is standalone with no Material-UI dependency, that it exposes notifications through a function call, and that it stacks and queues snackbars, with the prop list on the documentation site.

### Does notistack have tests?

The manifest defines a test script whose whole body is echo todo-test, so running the test command does not run any tests. The repository does carry seven example projects, including MobX and Redux integrations, which demonstrate usage rather than verifying behaviour.

## Sources

- [iamhosseindhv/notistack on GitHub](https://github.com/iamhosseindhv/notistack)
- [Issues](https://github.com/iamhosseindhv/notistack/issues)
- [Project website](https://notistack.com)
- [README](https://github.com/iamhosseindhv/notistack/blob/master/README.md)

---

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