Typist is Doist's Tiptap editor, and it says so about who it is for

A Tiptap component with a plain-text mode bolted on

Typist is a React component wrapping Tiptap, and it does three specific things beyond being an editor. It can render content read-only rather than as an editable surface, which is what lets the same component serve a viewer and an editor. It has a plain-text mode, and the repository topics list both rich-text and plain-text, markdown and plain-text editor variants. And it ships HTML and Markdown serializers. The package name is `@doist/typist`, the description calls it the editor that powers Doist products, and the dependency list pins Tiptap core at 2.27.3. The interesting design question is whether the plain-text mode is a second rendering path or a configuration of the same schema, and the README does not say, so a team that needs to switch modes at runtime will have to dig into the source and the Storybook rather than trust the summary.

The three props that are read once and never again

There is one warning in the usage section that deserves more attention than a note at the bottom of a README usually gets. `content`, `extensions` and `placeholder` are initialization-only: they are read when the editor first mounts, and later changes to these props are ignored. That is a deliberate design choice, and it makes sense in a component whose whole value is a stable editor instance with a fixed set of extensions, since rebuilding the extension set on every prop change would be expensive and would lose state. But it also means the common React reflex of treating the editor as a controlled component will not work here. The README points to a component lifecycle page in the documentation for how to handle runtime changes, and that page is not optional reading for anyone who has to load a different document into an editor that is already mounted.

Installing the package and mounting the first editor

Installation is a single npm command.

npm install --save @doist/typist

The usage example imports the editor component and a kit of extensions, and mounts the editor with a placeholder, the initial content and the extension list.

import { TypistEditor, RichTextKit } from '@doist/typist'

function TypistEditorContainer({ content }) {
    return (
        <TypistEditor
            placeholder="A full rich-text editor, be creative…"
            content={content}
            extensions={[RichTextKit]}
        />
    )
}

The shape to notice is `extensions={[RichTextKit]}`: the feature set is passed in as a value, not configured through a chain of props, so the editor's capabilities are whatever the kit contains. That is what makes the plain-text mode and the serializers possible, and it also means swapping a feature set means remounting the editor rather than reconfiguring it. The package is ESM only, with `dist/index.js` as the main entry and `dist/index.d.ts` for types, `sideEffects` set to false so bundlers can tree-shake it, and a single root export in the exports map.

What the project says about its own scope

The README carries a note that is worth quoting rather than paraphrasing: the project is not attempting to be an all-purpose rich-text editor, and while everyone is welcome to fork or use the package in their own products, development decisions are centered around Doist product requirements. That is an unusually clear statement of intent from a company that publishes its internal editor, and it changes how you should evaluate the project. You are not adopting a neutral community library; you are adopting a component that will be shaped by what Doist needs next, and the dependency on a particular Tiptap version is part of that. The README also lists a curated set of other Tiptap based editors to draw inspiration from, naming GitLab's content editor as the reference point, which tells you what the maintainers consider comparable work.

Modern toolchain, current release cadence, strict engine floors

The repository layout shows a project kept on a current toolchain. The package manifest requires Node 24.13.0 or newer and npm 11.5.1 or newer, which is a real constraint: a team on an older Node will not install it. The build uses tsdown, the postbuild step runs publint to check the published package shape, and the scripts use npm-run-all for sequencing clean, build, fix and check targets. Formatting and linting are handled by oxfmt and oxlint rather than prettier and eslint, types are checked with tsc, and tests run under vitest with a `vitest.setup.ts` and a separate `vitest.config.mts`. Lefthook manages git hooks, and release.config.js drives semantic-release with conventional commits, which matches the release badge. Recent releases are frequent: v17.0.3 on 2026-09-16, v17.0.4 on 2026-10-02 and v17.0.5 on 2026-10-09, with the last push on 2026-10-21.

Storybook is the documentation, and the docs live in the repo

The documentation strategy is unusually dependent on a live environment. The README sends readers to a Storybook for additional documentation, in-depth examples and a live demo, and the homepage for the project is the documentation site itself. The repository carries a `stories` directory and a `.storybook` configuration, and the dev script runs `storybook dev --port 6006 --ci`, so the local documentation is the same artefact as the published one. There is also a `docs` directory with the pages the README links to, including the component lifecycle notes. This has a practical consequence for teams with strict documentation requirements: the rendered documentation is not a set of files you can read in a pull request, it is an application. The Storybook can be built into static output with the build script, but the source of truth for the behaviour is the component and its stories, so a change in behaviour is visible in the diff of the stories rather than in prose.

Licence and what it does not cover

The licence is MIT style, with the text in the LICENSE file, so you can use the package in a proprietary product without extra obligations beyond keeping the notice. The project also publishes a Contributor Covenant badge and a CODE_OF_CONDUCT file, and the contributor guide lives in CONTRIBUTING.md, so outside contributions are structured rather than ad hoc. What the README does not cover is any of the operational questions a team usually asks before taking on a component like this. There is no stated support policy, no list of browser support, no accessibility notes, no statement about which ProseMirror or Tiptap features are deliberately excluded, and no documentation of the read-only mode's behaviour. The repository also carries an `AGENTS.md` and a `.agents` directory, which suggests the project is developed with AI coding assistants in the loop, a practice worth being aware of when you assess how changes are reviewed.

Editorial conclusion

Adopt Typist if your product needs a rich-text editor that already handles plain-text mode and HTML and Markdown output, and you are willing to work within a component whose props are fixed at mount time. Do not adopt it as a general-purpose editor foundation, since the project states that development decisions are centered around Doist product requirements. Before you start, read the component lifecycle documentation, because `content`, `extensions` and `placeholder` are read once when the editor mounts and later changes to them are ignored.

Frequently asked questions

Official sources

1. Doist/typist on GitHub
2. License: MIT
3. Project website
4. README
5. Releases