TinyEditor is a Quill 2.0 editor with 30 extra modules and Quill's own API intact

What it is: Quill 2.0 plus the modules Quill never shipped

TinyEditor is described as a rich text editor based on Quill 2.0, which extends Quill with rich modules and formats such as table, image, link, clipboard, emoji, file, mention, and quick menu. The three claims it makes about itself are that it is framework-independent, compatible with the Quill API, and compatible with the Quill module ecosystem.

The scale is stated precisely. The README says the editor contains more than 30 modules and formats, in addition to the 21 built-in formats in Quill, and that it extends and enhances 15 modules and formats such as table, image, link, counter, emoji, file, clipboard, mention, quick menu, screenshot. So the shape of the project is a superset: Quill's own formats, plus fifteen more, with some of Quill's existing ones improved.

That last part matters. The word extends and enhances rather than simply adds covers cases where a Quill module exists but is thin, and the Credits section names the upstream projects the work is based on, which tells you where the improvements came from.

The framework independence claim is explicit: it is not related to frameworks and can be used in multiple frameworks such as Vue, React, Angular, etc. That is a genuine constraint on how it is built, since Quill itself is framework-independent but many extensions assume a particular view layer.

The repository metadata gives the same picture from the packaging side. The package name is @opentiny/fluent-editor, the licence is MIT, and the homepage is the OpenTiny documentation site. The topics list editor, fluent-editor, opentiny, quill, rich-text, rich-text-editor, tiny-editor, wysiwyg and wysiwyg-editor, so the Quill lineage is part of how the project positions itself.

The default branch is dev, and the release history lists v4.1.2 and v4.1.1 alongside v3.25.12, which tells you there are two maintained lines rather than one.

The table module is the one the README describes in detail

The feature list devotes its most detailed entry to tables, and that is a good signal about where the effort went.

The README describes a powerful table function, supporting inserting a table with specified rows and columns in the toolbar, table row height and column width dragging, inserting rows and columns, deleting rows and columns, merging and splitting cells, and other rich table operations.

Each of those is a discrete piece of work. Inserting rows and columns at a given position, not just appending at the end. Dragging a column width, which means handling pointer events on a boundary and recomputing layout. Merging and splitting cells, which in a delta-based editor means rewriting the underlying cell attributes rather than just toggling a flag.

The Credits section says where the table work comes from: the quill-better-table project, which enhances the built-in table module of Quill and adds rich functionality, and TinyEditor's table operation functionality is based on it. So the table module is a reimplementation of an existing Quill extension rather than something written from scratch, which is a sensible thing to do and worth knowing if you are already using quill-better-table elsewhere.

The other credited modules follow the same pattern. The quill-emoji project is a Quill module for emoji, and TinyEditor's insert emoji function is based on it. The quill-blot-formatter project is a Quill module for resizing images and videos, and TinyEditor's image scaling function is based on it.

So the architecture is a layered one: Quill 2.0 provides the core editor, the clipboard and the format system; a set of community Quill modules provides the specific capabilities; TinyEditor integrates them, improves them and exposes them through one toolbar and one package. That is a different proposition from writing an editor, and it is the reason the Quill API compatibility matters so much.

Installing and initialising takes one import and one constructor

The quick start is four steps and it reads like any other DOM-based editor.

First the package:

npm i @opentiny/fluent-editor

Then a container element in your page:

<div id="editor">
  <p>Hello TinyEditor!</p>
</div>

Then the stylesheet, which is a separate import:

@import '@opentiny/fluent-editor/style.css';

And then the editor itself:

import TinyEditor from '@opentiny/fluent-editor'

const editor = new TinyEditor('#editor', {
  theme: 'snow',
})

The constructor takes a selector and an options object, and the theme option takes the value snow. That single theme name is a Quill concept, since Quill ships a snow theme and a bubble theme, and it confirms the API compatibility claim in practice rather than in the abstract: a Quill option name works unchanged.

The package metadata in the repository root is the workspace root rather than the published package, and it explains the build. The package manager is pnpm at version 9.13.0, and the workspace is organised with pnpm-workspace.json and a packages/ directory. The scripts show the layout: the dev script runs pnpm -F docs dev for the documentation site, the watch script runs pnpm -F @opentiny/fluent-editor dev for the library itself, build:lib builds the library and then runs a pre-release step, and pub publishes the fluent-editor package. There are separate build:v3 and build:projects scripts for the older line and the example projects, and the lint script runs eslint with a cache.

The testing entry point is the docs package rather than the library, which is an unusual arrangement worth noting: the test script is pnpm -F docs test, and there is a jest.config.js at the root.

The Quill patch in pnpm is the mechanism worth understanding

The most interesting line in the root package.json is the pnpm section, and it explains how TinyEditor stays Quill-compatible without forking Quill.

  "pnpm": {
    "patchedDependencies": {
      "[email protected]": "patches/[email protected]"
    }
  }

pnpm's patchedDependencies mechanism applies a patch file to a dependency at install time, and the repository carries a patches/ directory with [email protected] in it. So Quill 2.0.3 is patched, not replaced.

This is a meaningful architectural decision with real consequences. The upside is that TinyEditor is not a fork. Quill's own releases keep flowing through, the module ecosystem stays intact, and any fix upstream applies to everyone using Quill, patched or not. The downside is that the patch is pinned to one exact version, 2.0.3. When Quill moves to 2.0.4, the patch has to be re-based, and until it is, the workspace cannot simply bump the dependency. That is the upgrade cost of the whole approach, and it is a real one for a project that wants to track Quill.

There is a second reason a patch might be needed. Extending Quill from the outside means working with Quill's internals in places where Quill does not expose a supported extension point, and a patch is the way to reach them without forking.

The rest of the tooling is worth noting too. The lint setup uses @antfu/eslint-config with eslint 9, eslint-plugin-format and lint-staged, and the git hooks are configured as pre-commit with lint-staged and a commit-msg hook running verifyCommit.js, so commit messages are validated by a script at the repository root. There is also an .npmrc, an eslint.config.mjs and a .all-contributorsrc, the last one driving the contributors list in the README.

The project uses pnpm as the package manager, which matters for contributors, since the workspace scripts, the patch mechanism and the lockfile all assume it.

Where TinyEditor is the wrong choice

The first limitation is that it inherits Quill's constraints along with Quill's strengths. Quill's editor model is built around a Delta document and a set of Blot renderers, and the clipboard, the undo stack and the selection handling all follow from that design. Choosing TinyEditor means accepting that model, including its known sharp edges. The README's own Credits section describes Quill as an API-driven rich text editor with a modular architecture, good scalability, ease of use and cross-platform support, and the list does not include a caveat, which means the real caveats are in Quill itself.

The second limitation is the patch pin. As described, the Quill dependency is fixed at 2.0.3 with a patch applied. If your application already uses a different Quill version, or if you need to move to a newer one for a security fix, that is a coordination task between you and the patch, not something you can do yourself.

The third limitation is the size of the surface. More than 30 modules and formats means more toolbar, more CSS and more code to review, for a product that may only need a subset. The count of features is a description of what is available, not a recommendation of what to enable, and there is no indication in the README that individual modules can be excluded from the build to keep it lean.

The fourth is the documentation shape. The homepage points at a documentation site, and the README itself is short and refers to the site for detail, with an English and Simplified Chinese pair. If you need to know the exact behaviour of a specific toolbar control, that is a site lookup rather than a README read, which is normal for a project of this size but means the README alone will not answer most integration questions.

The alternative to weigh is Quill itself, or a different editor entirely. Quill alone is the smaller choice and has a clean module ecosystem of its own, so if the missing pieces are one or two formats rather than a dozen, the community modules that TinyEditor itself credits may cover the gap with less machinery. The other direction is a modern framework-specific editor such as TipTap, which is built on ProseMirror rather than Quill and therefore has a different document model and a different plugin architecture. The difference in approach is exactly that: TinyEditor is the Quill-shaped answer to the problem of Quill's feature gaps, and TipTap is the ProseMirror-shaped answer. If your application already has an editor, the cost of switching is measured in how much of the Quill model you would be porting, not in the number of features either editor offers.

Versions, licence and the shape of the repository

On maintenance, the last push was on 2026-09-11 and the repository is not archived. The release history lists v4.1.2 on 2026-07-24, v4.1.1 on 2026-05-07 and v3.25.12 on 2026-07-28, and the presence of a build:v3 script in the root package.json matches the two maintained lines.

The licence is MIT, recorded in the package.json and with a LICENSE file at the repository root, and the README links it under a License heading. That is a permissive grant with no copyleft obligation on code you build with it, which is a licensing note rather than legal advice. It covers the TinyEditor code; the Quill code it patches and the community modules it builds on carry their own licences, and Quill is MIT licensed, so the stack is consistent.

The repository layout reflects a monorepo with a documentation site alongside the library. There are packages/ for the workspace members, docs/ inside it with the dev, build and test scripts pointing at it, projects/ for the example applications with their own dev and build scripts, patches/ for the Quill patch, and a pnpm-workspace.yaml at the root. There is also a .vscode/ directory, a .npmrc, an eslint.config.mjs, a jest.config.js, and separate CONTRIBUTING.md and CONTRIBUTING.zh-CN.md files.

That the tests live in the docs package is the one structural oddity worth flagging. The test script is pnpm -F docs test and the report script is pnpm -F docs report, so the end to end tests run from the documentation workspace rather than from a package adjacent to the code they test. For a project where the docs site doubles as the demo, that is a reasonable arrangement, but it does mean the test suite and the documentation share a dependency set.

The README's Credits section is also more informative than the feature list, because it tells you which parts are TinyEditor's own work and which are adaptations. The table operations come from quill-better-table, the emoji insertion from quill-emoji, and the image scaling from quill-blot-formatter. Quill itself is credited as the base. The README gives Quill's own description as an API-driven rich text editor with a modular architecture, good scalability, ease of use and cross-platform support, and that is the foundation TinyEditor extends.

Editorial conclusion

Adopt TinyEditor if you need Quill's API and module ecosystem but also need the table, image, mention and quick menu features Quill leaves out, since that is the specific gap it fills. Do not adopt it if you want a small editor with no Quill lineage, because every Quill module you pull in also pulls in Quill's conventions. Verify first which Quill version your application already uses, since TinyEditor is built against 2.0.3 and applies a patch to it, and that the 15 extended modules cover the formats your users actually need rather than assuming the count is enough.

Frequently asked questions

Official sources

1. License: MIT
2. opentiny/tiny-editor on GitHub
3. Project website
4. README
5. Releases