reactjs-tiptap-editor dresses Tiptap in shadcn components

Tiptap does the editing, shadcn does the look

The project is described as a modern WYSIWYG rich text editor based on Tiptap and shadcn ui for React, and the readme restates it as a modern WYSIWYG rich-text editor based on Tiptap that uses shadcn components. That division is the whole product. Tiptap, the ProseMirror based editor, handles the document model, the marks and the extensions, and the package supplies the presentation layer and the React glue around it. The alternative to this package is therefore not a different editor but a different amount of work, since assembling Tiptap with a component set is a project of its own. The two related projects are linked at the bottom of the readme, Tiptap and shadcn, and the package is published to npm as reactjs-tiptap-editor with a live demo at reactjs-tiptap-editor-playground.vercel.app and the documentation hosted on the same vercel domain as the main site. The licence is MIT.

Every extension is its own entry point, and that is the packaging idea

The package.json is the most informative file in the repository, because the typesVersions map gives every extension a subpath. The list runs through attachment, blockquote, bold, bulletlist and clear already by the point it is truncated, and each maps to a file under lib/extensions/ with a matching name. The published files are lib, LICENSE, package.json and README.md, with a main pointing at a CommonJS build, a module field pointing at the ESM build and types pointing at the declarations, so the package ships both module formats. There are also dedicated subpaths for locale-bundle, bubble and theme, and a catch-all mapping to lib and the root. The practical effect of that structure is that a consumer who imports only the bold extension does not pull the rest of the editor into the bundle, and the readme points at a bundle size report with before and after comparisons to back that up. This is the concrete reason to prefer the package over wiring Tiptap up by hand.

The documented surface is small, and the docs are the reference

The readme itself is thin, and the documentation lives in the docs/ directory instead. The three guides the readme links are Getting Started for the current source API, individual bubble imports, and selective locale loading, and there is a reports/bundle-size/REPORT-ROUND2.md with the bundle measurements and before and after comparisons. The existence of that report says something about the project's priorities, since bundle size is treated as a first-class feature rather than an afterthought, and the selective locale loading guide suggests the same for internationalisation, where shipping every language to every user is the default failure mode. The repository layout backs this up, with docs/, reports/, playground/, src/, tests/, skills/, a scripts/ directory, a components.json for shadcn, tailwind.config.js, postcss.config.js, vite.config.ts and a pnpm-workspace.yaml.

Running it locally is a clone, an install and a playground

The local workflow is four steps and it is worth noting that the build script is a library build rather than the usual next dev.

git clone https://github.com/hunghg255/reactjs-tiptap-editor.git

cd reactjs-tiptap-editor

pnpm install

And then the two commands that start the demo.

npm run build:lib:dev
npm run playground

The build of the library comes first, in a development variant, and only then does the playground start. That ordering is a consequence of the package layout, where the playground consumes the built library rather than the source, so a change to the source needs a rebuild before you see it. The pnpm workspace file and the pnpm-lock file are what pin the dependency graph, and the presence of a skills directory with a skills-lock.json suggests the repository ships agent instructions for contributors, alongside the .agents/ and .claude/ directories and a CONTRIBUTING.md.

The toolchain is modern and mostly oxlint plus oxfmt

The repository configuration shows a project that has moved to a current generation of tooling. There are.oxfmtrc.json and.oxlintrc.json files, so linting and formatting are handled by oxlint and oxfmt rather than the older eslint and prettier combination, and there is a.vscode directory. The presence of a.git-blame-ignore-revs-style file is not there, but the.github directory carries the workflows, and the release history is dense, with v1.0.46 on 2026-09-18, v1.0.45 and v1.0.44 both on 2026-09-15, which is a release pace typical of a component library that ships an extension at a time. The package keywords list the alternative names the package is known by, tiptap-react-editor, tiptap-react-rich-text, tiptap-react-wysiwyg and similar variants, which is a sign of a package that has been renamed and repackaged more than once.

Where this is the wrong choice

Three limits are worth naming. The first is that the editor choice is made for you. If your team has not already decided that Tiptap is the right ProseMirror-based editor, this package is one step along a path you have to take anyway, and the readme's own topic list shows the alternatives that exist, with ckeditor, lexical, platejs and wangeditor all named as neighbouring choices. The second is React only. The package is a set of React components with shadcn styling, so a Vue, Svelte or Angular team gets nothing from it, and even a React team that has standardised on another component library will end up mixing two systems, since shadcn is copied into your project rather than installed as a library. The third is that the visual style is not yours. A WYSIWYG built from shadcn components looks like shadcn, and a product with its own typography and spacing will spend time overriding it, and the components.json in the repository root suggests the design tokens live in your project and are easy to adjust, which is a feature and a cost at the same time. A last practical point is that a rich text editor is easy to start and hard to finish, because the moment you add collaboration, comments, tables, or a custom schema you are maintaining ProseMirror extensions rather than consuming them.

Editorial conclusion

reactjs-tiptap-editor suits a React team that has already chosen Tiptap and wants a decent looking editor without designing one, and it suits anyone whose bundle is dominated by editor extensions they never enable. It is the wrong tool for a project that has not picked an editor, because the choice of Tiptap and shadcn is made for you, and it is the wrong tool if you need a non React framework. Before adopting it, read the getting started guide and the bundle size report, since the subpath export structure is the main reason to choose this package over assembling Tiptap yourself, and check which locale files your interface actually needs since selective loading is a separate feature from the extension split. The last push was on 2026-10-20 and the current release is v1.0.46 from 2026-09-18.

Frequently asked questions

Official sources

1. hunghg255/reactjs-tiptap-editor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases