# editorcn, one CLI install and a monorepo root with nothing published

> editorcn copies React rich text editor components into a project through the shadcn CLI instead of publishing a package. The repository root is a private pnpm and turbo workspace that builds a registry, and what the README promises and what the root package.json shows do not quite line up.

**shadcn-labs/editorcn** — Beautiful rich text editor components for React, built on Tiptap. 100% Free, Zero config, one command setup.

- Repository: https://github.com/shadcn-labs/editorcn
- Website: https://editorcn.vercel.app
- Stars: 332 · Forks: 18
- Language: TypeScript
- License: MIT
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/shadcn-labs-editorcn

## Zero config is promised three times and never shown once

The project description leads with 100% Free, Zero config, one command setup. The badge line under the title repeats it as Zero config. One command setup. A third line, in the feature list, spells out what zero config is supposed to mean: it works out of the box with sensible defaults.

Three claims, one sentence of substance. Nowhere in the README is there a command, a props table, or a defaults object, so what those sensible defaults are cannot be learned from the repository root. The same tension runs through the feature list, which also promises that icons, labels, colors, and controls can be overridden via props. A component you can override is a component with settings, and a component with settings is a different thing from a component with none. The zero config line and the customizable line are both true about different layers, and the README never says which is which.

## The root package is private, so there is nothing on npm to install

The root package.json opens with three lines that decide how you get this code. The name is editorcn. The private field is true. The workspaces field lists apps/* and packages/*.

Private plus workspaces means this is a monorepo root that exists to build and publish something else, not a library you add to your own dependency list. Nothing here is arranged for npm consumption, and the README does not pretend otherwise, since the installation path it names is the shadcn CLI, which copies component source into your project rather than linking a package. That is a coherent design for a component registry. It also means the version you receive is whatever the registry item points at, and the registry is the only place where a version choice exists at all.

## Tiptap is in the description and absent from the dependency list

The description says the components are built on Tiptap, and one feature line says Tiptap powered, promising full access to the Tiptap editor ecosystem. The root dependency list contains three entries: an internal environment package, dotenv, and zod. No editor framework, and no Tiptap.

That fits the copy-source-in model rather than looking like an oversight, because the files your project receives carry their own imports. It does mean the framework version is decided by whatever the generated registry content says at install time, with no lock on it anywhere in this repository. If a Tiptap major version changes how extensions are registered, the version you inherit comes from a script output rather than from a version field you can read.

## The shadcn CLI install is a hyperlink, not a command

The README describes installation in prose: install via shadcn CLI. It then points at four pages on the project's own documentation site, a Get Started page, an Installation page, an Editor page, and a Block Editor page.

So the exact command lives one click away on editorcn.vercel.app and not in the repository. For a project whose whole pitch is one command setup, that is a notable split, because the marketing line and the instructions live on two different hosts and the repository copy of the instructions is a link. A reader resolves it in five seconds. It is also the kind of detail that goes stale quietly, since nothing in the README pins a version of the docs or names the command.

## Twenty toolbar controls with seven names between them

The feature list advertises more than twenty toolbar controls and then names seven categories: bold, italic, headings, lists, links, alignment, and embeds.

Seven names is the whole enumeration. There is no per-control documentation in the repository root, no props table, and no mapping from the Tiptap features the project says it exposes onto the controls a consumer actually sees in the toolbar. What the repository supports is that a toolbar exists and that embeds are in it. What it does not support is which embeds, whether headings stop at three levels, or whether alignment includes a justify option. All three answers are probably on the documentation site.

## Two workspace packages, three catalog entries, eight scripts

The dependency lists use two pnpm protocols a reader of the README would never meet. workspace:* covers two internal packages, one named env and one named config. catalog: covers dotenv, zod, and typescript, which means their versions are declared once in a shared catalog rather than repeated per workspace. The package manager is pinned at pnpm 10.12.4 and the task runner is turbo.

The eight scripts show the shape of the build.

```json
"scripts": {
  "dev": "turbo dev",
  "build": "turbo build",
  "build:registry": "node scripts/build-registry.mjs",
  "typecheck": "turbo typecheck",
  "check": "ultracite check",
  "fix": "ultracite fix",
  "dev:web": "turbo -F web dev",
  "prepare": "lefthook install"
}
```

Six of the eight are thin wrappers around a tool. Two are not, and they matter. The registry build runs a project script instead of a binary, and the prepare hook wires up git hooks through lefthook as part of installation, which means the checkout configures itself before you run anything.

## One undocumented script builds the registry, and there are no releases

scripts/build-registry.mjs is the only script in the root package.json that is not a wrapper around a tool, and it is the one that matters most, because it produces the registry item the shadcn CLI reads. The README does not describe what it emits, where the output goes, or how a component is added to it.

Meanwhile the repository has no GitHub releases at all. There is no tag history to consult and no changelog among the root entries, which are the usual governance files, two lint and format configs, the workspace and turbo configuration, and the lockfile. The last push to the main branch is 26 September 2026, so the code is current, but current code with no published versions means a consumer installs whatever the registry holds at that moment and has no documented release to pin against.

## Vulnerabilities go to advisories, everything else goes to issues

The root entries include SECURITY.md, CODE_OF_CONDUCT.md, and CONTRIBUTING.md, and the README points at all three. Security reports are directed away from the public issue tracker and into GitHub Security Advisories, with an explicit request not to open a public issue for a vulnerability. Contributions are directed to the contributing guide, with issues and discussions named as the collaboration venues, and taking part in the project is framed as agreement to the code of conduct. Contributors are credited through a generated graph rather than a hand-maintained list.

The split between the two venues is the part that has teeth. Questions, ideas, and bug reports go somewhere public and searchable. Vulnerabilities go somewhere private. For a component set whose output gets copied into other people's repositories, that separation is what keeps an unpatched flaw from being announced in a public thread.

## Conclusion

editorcn is worth adopting if you already run shadcn and want Tiptap components as copyable source rather than a versioned dependency, and you are comfortable pinning the framework version yourself. Check three things first: whether the registry item you install names a Tiptap version you can live with, whether your build can consume the files the CLI drops in, and whether you need the four documentation pages on the project site to be reachable, because the README carries no install command of its own.

## FAQ

### Is editorcn published on npm?

No. The root package.json sets private to true and declares apps/* and packages/* as workspaces, and the repository has no GitHub releases. The documented installation path is the shadcn CLI, which copies component source into your own project instead of linking a package.

### Does my project need Tiptap before installing editorcn?

The README calls the components Tiptap powered, but Tiptap is not in the root dependency list, which holds an internal environment package, dotenv, and zod. Because the CLI copies source into your app, the framework arrives through the copied files rather than through a declared dependency of this repository.

### How much of editorcn's toolbar is documented in the README?

The feature list promises more than twenty toolbar controls and names seven categories: bold, italic, headings, lists, links, alignment, and embeds. Overriding icons, labels, colors, and controls through props is also promised. No props table and no per-control list appear in the repository root.

### When was editorcn last updated and does it have releases?

The last push to the main branch is 26 September 2026 and the repository is not archived. There are no GitHub releases and no changelog at the root, so there is no tag history to pin a consumer install against.

## Sources

- [Issues](https://github.com/shadcn-labs/editorcn/issues)
- [License: MIT](https://github.com/shadcn-labs/editorcn/blob/main/LICENSE)
- [Project website](https://editorcn.vercel.app)
- [README](https://github.com/shadcn-labs/editorcn/blob/main/README.md)
- [shadcn-labs/editorcn on GitHub](https://github.com/shadcn-labs/editorcn)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/shadcn-labs-editorcn