svelte-french-toast is a Svelte port of react-hot-toast, and its README is older than its code

A port of a React library, with the original licence

svelte-french-toast is described as buttery smooth Svelte notifications, and the readme is direct about what it is. It is a Svelte port of Timo Lins's react-hot-toast, a lightweight, customizable, and beautiful-by-default toast notification library.

That lineage is visible in more than the API shape. The Thanks section in the readme reproduces the MIT licence text of the original React Hot Toast, with the copyright line naming Timo Lins and the year 2020, and it says thanks to the original author and its contributors.

This is the correct thing to do for a port, and it is worth checking rather than assuming. A port carries the design of the original, so the original's licence travels with it, and the readme making that explicit means you do not have to go looking for the upstream repository to work out what you are allowed to do with it. The project itself is MIT licensed, with a LICENSE.md at the top of the repository, and the author is Kabir Goel.

The library is small, and the readme says so, describing it as lightweight, customizable and beautiful by default. The website for more usage examples is at svelte-french-toast.vercel.app, and the package is on npm as svelte-french-toast.

One component to mount, one function to call

The basic usage is the whole API, and it takes a handful of lines.

<script>
	import toast, {Toaster} from 'svelte-french-toast'

	function handleClick() {
		toast.success('Hello, world!')
	}
</script>

<Toaster />
<button type="button" on:click={handleClick}>Toast</button>

The pattern is the same as the React original. You mount a Toaster component once at the top level of the application, and then anywhere in the tree you call the toast function to display a notification.

The success call in the example shows that the toast function has typed variants, and the readme points to the website for the longer set of examples rather than enumerating them in the README. For a port this is the right division of labour, since the full API surface is long and the README stays short enough to be read.

The component is mounted at the top level rather than next to the thing that triggers it, which is the decision that matters for an implementation. A toast that renders where it was called disappears when the view that called it unmounts, so a single portal-like component at the root of the application is the only placement that survives navigation.

Svelte 5 and one runtime dependency

The package manifest makes the compatibility story explicit, and it is the part that needs attention before you install.

The peer dependency is svelte at ^5.0.0, so the package expects Svelte 5 and will not be satisfied by Svelte 4. There is a single runtime dependency, svelte-writable-derived at ^3.1.1, and the peer dependencies are kept separate from it so the host application controls the Svelte version and the library does not bring a second copy.

That is a small library with a narrow surface, which is a good sign for a component that ends up in every route of an application. A toast library is the kind of dependency that people are surprised to find pulling in a framework of its own, and this one does not.

The package is an ES module, with type set to module, and the exports map has a single entry.

"exports": {
  ".": {
    "types": "./dist/index.d.ts",
    "svelte": "./dist/index.js"
  }
}

The svelte condition in the exports map is the detail that matters for bundlers, because it tells a tool that can resolve the svelte export condition to pick the Svelte-aware build of the library, which is compiled with the Svelte compiler rather than shipped as raw components.

The build packages with svelte-package and checks itself with publint

The scripts section shows how the library is built and, more interestingly, how it verifies its own packaging.

The build is vite build followed by the package script. The package script runs svelte-kit sync, then svelte-package, then publint, and then copies the README and the header image into dist. The prepare script runs svelte-kit sync, and prepublishOnly runs the package script so that what gets published is exactly what was verified.

publint is the part worth knowing about. It is a checker for package exports, and it runs against the built package before anything is published. Running it as part of the package script means a packaging mistake fails the build rather than surfacing as a confusing resolution error in a consuming application.

The dev and preview scripts are the standard Vite ones, and the check script runs svelte-kit sync and then svelte-check with the project tsconfig, which is the type checking pass for a Svelte project. The formatting is handled by prettier with the prettier-plugin-svelte plugin and eslint-plugin-svelte for linting, and eslint-config-prettier keeps the two from arguing.

The published tarball contains only dist, per the files field, so the source and the configuration do not ship.

Playwright for the behaviour, Vitest for the units

The test story is a two layer one, and for a component library that renders to a DOM it is the right split.

The test script runs playwright test, and the configuration file at the root is playwright.config.ts. There is a tests/ directory at the top level, and a unit test script that runs vitest.

The reasoning is straightforward. A toast library's behaviour is largely visual and temporal. Does the toast appear, does it animate, does it disappear on its own after the configured duration, does dismissing it early remove the right element, does the queue behave when several are triggered at once. None of that is meaningfully testable without a real browser and a real clock, so Playwright is where the meaningful assertions live.

Vitest covers the unit level, the pure functions, the store logic that keeps the queue, and it runs fast enough to run on every save. The website at svelte-french-toast.vercel.app is built with the SvelteKit adapter and Vite, and the repository has a static/ directory and a svelte.config.js, so the documentation site and the library are built from the same project with the same toolchain.

The version gap between the published line and the repository

The release list and the package manifest disagree, and that is the practical fact about this project today.

The published releases are v1.2.0 from 2023-07-23, v1.1.0 from 2023-06-28 and v1.0.3 from 2022-06-15. The version in the package manifest in the repository is 2.0.0-alpha.0, and the peer dependency there is Svelte 5.

So the 1.x line predates the Svelte 5 requirement, and the 2.0.0 alpha in the repository is the version that targets Svelte 5. If you install from npm today and you are on Svelte 5, the peer dependency is the thing to look at, because a 1.x release will not have that range.

The last push to the repository was on 2026-05-15, so the work is still happening, and the alpha suffix tells you the maintainer considers the 2.x API unsettled. A library that a team's whole notification flow depends on is not the place to be adventurous, so the practical question is whether the 1.x API is enough for what you need, and if it is, whether it works with the Svelte version you are on.

The rest of the tree is the modern Svelte toolchain. There is an eslint.config.js in the flat config format, a .prettierrc with a .prettierignore, an .npmrc, a pnpm-lock.yaml as the lock file, a vite.config.js, a postcss.config.cjs and a tailwind.config.cjs, and a tsconfig.json.

Editorial conclusion

Adopt svelte-french-toast when you want react-hot-toast behaviour in a Svelte 5 application and you are comfortable tracking an alpha. Do not pin the 1.x line for a Svelte 5 project, because the peer dependency in the repository is svelte ^5.0.0 and the 1.x releases predate that requirement. Verify first which version you actually install from the registry, since the README documents the 1.x API while the package manifest in the repository is at 2.0.0-alpha.0, and check that the upstream react-hot-toast licence attribution is preserved in anything you ship.

Frequently asked questions

Official sources

1. kbrgl/svelte-french-toast on GitHub
2. License: MIT
3. Project website
4. README
5. Releases