# svelte-lexical: Lexical editor bindings and higher level components for Svelte > svelte-lexical brings the Lexical rich text editor to Svelte through a set of plugins, wrapped as a pnpm workspace with demo projects for Svelte and SvelteKit. It is still on the 0.x line, and the plugin list, not the editor itself, is where most of the behaviour lives. **umaranis/svelte-lexical** — Rich text editor for Svelte based on lexical - Repository: https://github.com/umaranis/svelte-lexical - Website: https://svelte-lexical.vercel.app - Stars: 599 · Forks: 45 - Language: Svelte - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/umaranis-svelte-lexical ## The project is bindings plus components, not a rewritten editor svelte-lexical is a rich text editor for Svelte built on Lexical, the extensible text editor framework developed at Facebook. The stated purpose has two halves: provide Svelte bindings for Lexical, and develop higher level components using Lexical. That distinction is the design in one sentence. The editor engine, its document model, its selection handling and its command system come from Lexical. What this repository adds is the Svelte-shaped layer on top, plus convenience components that wrap common editor setups so you do not have to assemble them from the primitives yourself. The practical benefit is that you inherit a mature editor rather than building one. Writing a rich text editor from scratch means handling selection, undo history, IME input, clipboard formats, and the interaction between native contenteditable behaviour and your framework's reactivity. Lexical has already dealt with that, and the hard part of this project is the binding between Lexical's imperative API and Svelte's declarative one. The homepage is svelte-lexical.vercel.app, the package is published to npm as svelte-lexical, and the licence is MIT. ## Most of the functionality arrives as plugins The Plugins section is short and it explains the shape of the library: most of the svelte-lexical functionality is implemented through plugins, and the README points to a list of them in docs/plugins/readme.md. This is the pattern Lexical itself uses, and adopting it in a Svelte binding keeps the core small. A plugin is the unit that adds behaviour, and the list of plugins is effectively the feature matrix of the editor. If a plugin is not in that list, the capability is not there yet, and if it is, you can usually compose it rather than write it. For a team evaluating the library, that list is the document to read first, not the README. The README describes how to run the project and how the code is organised. The plugin list tells you what the editor can currently do, and it is a document that changes as the project grows. The size of the package is also treated as a first class concern. Size Limit controls the library size, which is a useful discipline for a component that every page that has an editor on it will pay for. ## The demo projects are the fastest way to understand the API The Getting Started section does not give you a copy and paste snippet. It tells you to pick one of the demo projects to understand how svelte-lexical can be incorporated into your project, and it names two: demos/sveltekit for a SvelteKit application and demos/playground for plain Svelte. That choice tells you something about the intended audience. The library is not opinionated about how you wire an editor into a route, so the demos carry the weight of documentation, and there are two of them because the two frameworks differ enough to matter. The build order is also specific. You build the library first, by changing directory to packages/svelte-lexical, installing dependencies with pnpm i, and building with pnpm build. Then you change to the demo directory and run pnpm dev. The library is not consumed from npm in the demos, it is built locally and linked, so a change to the bindings shows up in the demo without a publish step. The development notes give the shorter form of the same thing: to run a demo in development, execute pnpm -C demos/playground dev. ## A pnpm workspace with the library, the demos and the tooling side by side The repository is set up as a monorepo using pnpm workspaces, and the root package.json declares workspaces over packages/* and demos/*. The root package is private and named npm-monorepo, which is the usual placeholder for a workspace root that exists to hold configuration rather than to be published. The publishing story is automated. The npm package is published automatically on creation of a GitHub release using GitHub Actions, so the release tag is the trigger and the version in the package manifest is what gets shipped. The tooling choices are worth noting because they tell you what kind of project this is. ESLint is set up for VS Code, and the root devDependencies include the flat config packages, eslint-config-prettier, eslint-plugin-svelte, globals and typescript-eslint, with an eslint.config.mjs at the root. Prettier configuration sits in .prettierrc.json with a .prettierignore, and there is a codebook.toml for the component workshop tooling, which is the convention for a component library that wants documented examples. The pnpm configuration also restricts which packages may run build scripts, with onlyBuiltDependencies limited to esbuild and svelte-preprocess, which is a deliberate supply chain decision rather than an accident of setup. ## Three test layers and an automated publish The testing setup is described in the same development notes list, and it covers three different levels. Unit testing is set up for the svelte-lexical package using Jest and Testing Library. End to end testing is set up for the playground package using Playwright, so the demo application doubles as the end to end test target. And the build workflow and the tests workflow both have their own GitHub Actions badges at the top of the README, so the state of the pipeline is visible without clicking through. The split is a sensible allocation. A rich text editor has behaviour that only appears when you type, select, paste and undo, which is exactly what a browser level test is for, and a unit test at the component level cannot cover. The Playwright suite running against the playground means the thing developers actually look at while developing is also the thing the end to end tests drive. The downside of the arrangement is that the end to end coverage is tied to the playground, so features that exist only as library level plugins without a playground page will have less behavioural coverage. ## Maintenance is recent, but the package is still pre 1.0 The release history shows a project that is shipping steadily. Version 0.6.5 went out on 2026-07-15, 0.6.4 on 2026-02-09, and 0.6.3 on 2025-11-04. The last push to the master branch was on 2026-09-04, and the repository is not archived. Two things follow. The project is being worked on rather than abandoned, and the version number is still below 1.0, which in practice means you should expect breaking changes between minor versions. The 0.6 line has moved through five minor releases since late 2025, and the underlying Lexical dependency is itself a moving target, so a component library that wraps it inherits some of that churn. The one thing to be careful about is that the library is a thin wrapper by design. When Lexical changes its API, this package has to follow, and a patch release here may need a matching upgrade on your side. Reading the release notes before upgrading is worth the minute it takes. The homepage being a Vercel deployment is a small detail that fits the pattern: a documentation and demo site for a front end component library, with the code and the demos in the same repository. ## Conclusion Adopt svelte-lexical if you are building a Svelte or SvelteKit application and you want Lexical's editor model with a Svelte API rather than assembling your own binding layer, and you can accept a 0.x package where features arrive as plugins. Do not adopt it expecting the plugin set to cover the editing features you need today, because the README points to the plugin list as the place where functionality is defined. Before you start, read the plugin list under docs/plugins, and run the demos with pnpm -C demos/playground dev so you can see which components already exist before you write your own. ## FAQ ### What is svelte-lexical? It is a rich text editor for Svelte built on Lexical, the extensible text editor framework from Facebook. The project provides Svelte bindings for Lexical and higher level components built with it, and is MIT licensed and published to npm as svelte-lexical. ### How do I run the svelte-lexical demo projects? Build the library first by changing to packages/svelte-lexical, running `pnpm i` and then `pnpm build`, then change to the demo directory and run `pnpm dev`. The development notes give the shorter form: `pnpm -C demos/playground dev`. The demos are demos/sveltekit and demos/playground. ### How do I add features to the svelte-lexical editor? Most of the functionality is implemented through plugins, and the README points to the plugin list under docs/plugins/readme.md. That list is the place to see which capabilities exist and which you would need to build yourself. ### How is the svelte-lexical package published? The npm package is published automatically on creation of a GitHub release using GitHub Actions. The repository is a pnpm workspace covering packages/* and demos/*, with a private root package that holds the shared tooling configuration. ## Sources - [License: MIT](https://github.com/umaranis/svelte-lexical/blob/master/LICENSE) - [Project website](https://svelte-lexical.vercel.app) - [README](https://github.com/umaranis/svelte-lexical/blob/master/README.md) - [Releases](https://github.com/umaranis/svelte-lexical/releases) - [umaranis/svelte-lexical on GitHub](https://github.com/umaranis/svelte-lexical) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/umaranis-svelte-lexical