svelte-put is a monorepo of small Svelte building blocks, and its next majors already require Svelte 5

svelte-put publishes eighteen packages that are meant to be installed one at a time

The project describes itself as useful svelte stuff to put in your projects, and the practical shape of it is a pnpm monorepo holding a list of small packages under the @svelte-put scope. Nothing is a framework and nothing is a component library in the usual sense. Each entry is one narrowly scoped utility: a copy to clipboard helper, a keyboard shortcut action, a wrapper for IntersectionObserver, a wrapper for ResizeObserver, a lock scroll and hide scrollbar action, a drag to scroll behaviour, a click outside event, a move node on mousedown action, a popover action, a QR renderer that emits an img or an svg, an avatar component, a dynamic inline SVG component, a table of contents action, and two preprocessors. The scope naming makes the intent clear, since the monorepo is the distribution mechanism and the packages are the product. A developer who needs clipboard copy and nothing else installs one package and inherits one dependency tree.

The current releases are next majors, and the README tells you to migrate to Svelte 5

The most important operational fact about the project sits in a note near the top of the README: Svelte 5 is here, and the recommendation is to migrate to Svelte 5 and upgrade to the next major versions of the svelte-put packages. The recent releases confirm that this is the current shape of the repository. The three most recent tagged releases are all next versions published on the same day, 2026-10-13: @svelte-put/toc at 7.0.0-next.0, @svelte-put/preprocess-external-link at 2.0.0-next.0, and @svelte-put/inline-svg at 5.0.0-next.0. Every package in the monorepo therefore sits at its own version number, and the current generation is a new major line that targets Svelte 5. This is the kind of versioning decision that tends to be invisible until it breaks a build. If your project is still on Svelte 4, the packages you need are not the current ones, and the version you would install has to be chosen deliberately rather than by taking the latest tag.

Three mechanisms sit side by side: actions, components and preprocessors

The catalogue mixes three different kinds of extension point, and the difference in mechanism matters more than the difference in feature. Actions are functions you attach to a node, the pattern Svelte introduced for behaviour that needs a DOM element, and the table describes several of them in exactly those terms: an event for clicking outside a node, an action that moves a node on mousedown, an action that adds keyboard shortcuts to a node, an action that locks scroll and hides the scrollbar, and an action that adds drag to scroll behaviour. Components are reusable pieces of markup, which covers avatar and the dynamic inline SVG renderer. Preprocessors run over your source before compilation, and the two in this repository deal with markup transformation rather than runtime behaviour: one automatically adds an id and an anchor to selected nodes, the other is named for external link handling. The README itself notes that the table contains repeated short descriptions for some rows, so read each package's own README rather than trusting the summary column.

The build is turbo over pnpm workspaces, and releases run through changesets

The repository layout explains how eighteen packages move at different speeds. The root package.json declares workspaces for internals, configs and packages, and the top level tree also carries a sites directory for the documentation, internals for shared tooling, a turbo.json at the root, and per package directories under packages. The scripts are all turbo calls, and the release path is changesets.

"build": "turbo run build",
"ci:version": "changeset version && pnpm install --no-frozen-lockfile",
"ci:publish": "changeset publish && pnpm install"

The build script runs turbo run build, dev runs turbo run dev, and lint, format and dts each run the same pattern with the parallel flag. A .changeset directory at the root is where pending version bumps are recorded. The result is that a single change to one package can produce a release for that package only, which is the practical reason the README says the packages have self-managed release cycles. Nothing in the root manifest tells a consumer how to install a package, because the packages are published to npm individually, and the documentation site is where that guidance lives.

Node 24 and pnpm 10 are hard requirements of the workspace, not of each package

The root manifest states the toolchain expectations in two places, and they are worth reading before you clone anything. The engines field requires pnpm at 10.0.0 or newer and node at 24.0.0 or newer, and the volta field pins node to 24.14.0, while packageManager names pnpm at 10.32.1. The dependency set is broad in the usual monorepo way: turbo, changesets tooling, eslint with a flat config, prettier with the svelte and tailwindcss plugins, stylelint, publint, svelte-check and typescript at 5.7.2, with svelte itself at 5.37.1. The development setup also has tooling beyond the package manager: eslint.config.js, prettier.config.js and stylelint.config.js at the root, a lefthook.yaml for git hooks, and an .editorconfig plus .prettierignore. None of that ships to a consumer of an individual package, but all of it shapes how you work if you clone the repository rather than install from npm.

What the table does not tell you, and why each package has its own README

The package table is the entry point and it is also thin. It gives you a short description, a version badge, a changelog link and a documentation link, and it explicitly tells you to check out the corresponding README for more details. Several rows carry descriptions that were clearly copied, since the clickoutside entry and the cloudflare-turnstile entry carry the same description, and the preaction and popover entries repeat the move node on mousedown text used by movable. One package name deserves a note as well: @svelte-put/cloudflare-turnstile is listed with a click outside description, which does not match what the name suggests, so the safe assumption is that this listing is out of date rather than that the package is misdescribed by its own documentation. The repository also carries a commented out In the Pipeline section listing packages planned for the future, which tells you the catalogue is expected to keep growing, and it does so on the author's own schedule, since the note says they will be added as soon as there is time and the implementation has matured.

A local action file versus an installed package, and where a framework would differ

The honest comparison here is not against a competing Svelte library, because the alternatives in this space tend to differ in kind rather than in scope. Writing the behaviour yourself means one small action function in your own source tree, with no version to track and no upstream release to react to. That is a reasonable option for something like a click outside handler, where the implementation is a handful of lines of document and window listener code. The case for the package is different for the larger entries. The table of contents entry is described as an action and utilities for building a table of contents, which implies parsing headings out of rendered markup and generating navigation, and the inline SVG component inlines SVG content dynamically, which involves fetching and parsing markup rather than a listener. For those, the implementation cost is high enough that a maintained package wins, while for a two line action it does not. A framework would differ by owning the whole application shell, which this project explicitly does not attempt.

Editorial conclusion

svelte-put suits a Svelte 5 team that keeps rewriting the same small pieces of interface logic and would rather install a maintained package than maintain a local copy. It is a poor fit for a project pinned to Svelte 4, because the current generation of the packages ships as next major versions, and it is also a poor fit if you want one dependency with one version to track, since the packages are published separately with independent release cycles. Before adopting anything from this monorepo, check which of the eighteen packages you actually need and read that package's own README, then confirm the Node and pnpm versions in the root package.json, which require Node 24 or newer and pnpm 10 or newer. The last push was on 2026-10-13, and the repository is not archived.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vnphanquang/svelte-put on GitHub