wangEditor-next keeps the wangEditor package names alive on Slate

A fork that inherits the package name, not the roadmap

wangEditor-next is a fork of the earlier wangeditor project, and the reason for the fork is stated plainly in the README: the original project was, for personal reasons of the original author, not maintained in the short term, so this fork continues maintenance while trying to avoid breaking changes as far as possible.

That inheritance is why the packages are named the way they are. The npm scope @wangeditor-next is used for the core editor and for every framework adapter, and the README says all official @wangeditor-next runtime packages use the same version number in each release and are published from a single monorepo through a single release process. For a team that already has @wangeditor-next/editor in its dependency tree, that continuity is the main argument for staying.

The project positions itself as an open source web rich text editor, ready to use with simple configuration, supporting JavaScript, Vue and React. The repository description adds markdown support and multi person collaboration, and the README lists ease of use, multi framework support, customisability and a small footprint as its characteristics.

The repository layout backs the monorepo claim. Top level entries include a packages directory for the published packages, an apps directory for the demo applications, shared, scripts, tests and docs directories, and the usual monorepo tooling: pnpm-workspace.yaml, pnpm-lock.yaml, turbo.json, a changesets directory for versioning, husky hooks, and Playwright and Vitest configuration files. There is also a README-en.md next to the Chinese README, and an AGENTS.md at the root.

Installing the editor and the adapter your framework needs

The install is split by target, and the split is the first thing to get right. The core editor package is installed for every use, and each framework has its own adapter package that must be installed alongside it:

npm install @wangeditor-next/editor --save
npm install @wangeditor-next/editor-for-vue --save
npm install @wangeditor-next/editor-for-vue2 --save
npm install @wangeditor-next/editor-for-react --save

The README notes in comments which line belongs to which framework: the editor-for-vue package is for Vue 3, editor-for-vue2 is for Vue 2, and editor-for-react is for React. Installing the core editor alone leaves you without the wrapper your framework expects.

If you are not using a framework, or you want a quick look, the README also documents a CDN route that pulls the built bundle directly:

<script src="https://unpkg.com/@wangeditor-next/editor@latest/dist/index.js"></script>

The online demos are hosted on StackBlitz, with separate entries for HTML, Vue 2, Vue 3 and React. The README is careful about how you treat those sandboxes. It says the real source of the demos in the repository is maintained under apps, listing apps/demo-html, apps/demo-react, apps/demo-vue3, apps/demo-yjs-react and apps/demo-yjs-vue3, plus a Vue 2 adapter regression page at apps/demo-html/examples/framework-vue2.html. It then states that the StackBlitz links are for online reproduction and sharing, that the apps directory is what is actually maintained, and that the sandbox code should not be treated as a long term source.

The local commands for the same demos are:

pnpm demo:html
pnpm demo:react
pnpm demo:vue3
pnpm demo:yjs:react
pnpm demo:yjs:vue3

There is also a template export path for teams that want to fork the demo setup, using pnpm demo:export-template with a target directory argument, and a documented way to keep a template repository in sync by configuring the repo variables and secret that the .github/workflows/export-demo-templates.yml workflow needs.

One version number across every published package

Version alignment is treated as a release rule rather than a convention. The README states that when React, Vue 2 or Vue 3 projects upgrade the editor, they should upgrade the matching official adapter at the same time, and that all official @wangeditor-next runtime packages share the same version number in every release because they come from one monorepo and one release process.

In practice that means the package.json of the core editor and the package.json of your adapter should never disagree. A project that bumps the editor and leaves the adapter behind is running two versions of a library that expect each other.

The release machinery is changesets based. The package.json scripts show the flow: pnpm changeset publish for publishing, pnpm changeset for creating a changeset, pnpm changeset version:release for versioning, and pnpm build as the prerelease step that runs before publishing. The build script is guarded by checks that run before anything ships:

    "build": "pnpm check:release-group && pnpm check:umd-globals && cross-env FORCE_COLOR=1 turbo build && pnpm check:published-types && pnpm check:published-entrypoints",

Those four checks are worth understanding as a contract with users. The release group check keeps the packages in step, the UMD globals check protects the CDN style bundle that the unpkg script tag above relies on, the published types check guards the TypeScript declarations that consumers import, and the published entrypoints check confirms that the files the package.json points at are actually shipped. For a project whose main distribution channel is npm, that is a more interesting set of guarantees than the README's short feature list suggests.

The root package.json is marked private and names [email protected] as the package manager, which is why the demo commands use pnpm rather than npm.

v6 changed video alignment into an explicit block model

The one concrete breaking change the README documents in detail is in video handling, and it shows the fork doing real migration work rather than only republishing. In v6, the built in video alignment option was changed to an explicit block level media layout: video nodes use align: 'left' | 'center' | 'right', and the rendered and exported HTML uses a responsive figure container.

The migration path is not a hard cut. The README says that video HTML using the old text-align attribute can still be imported, and is converted automatically into the new alignment model. That matters for anyone with stored content, since a rich text editor is judged as much on what it does with documents that already exist as on what it produces for new ones.

The README points to the v6.0.0 release notes for the full change list rather than repeating it, which is a reasonable convention but also means the README alone is not a complete upgrade guide. If you are coming from v5, read those notes before you migrate stored content.

The scope of the change also illustrates the shape of this project. It is not a rewrite with a new editor model. It is a continuation of the wangEditor design, in slate.js, with the video block being reworked to fit how slate represents block level attributes. The fork's stated goal, avoiding breaking changes where possible, is doing real work in exactly the places where slate's data model forces the issue.

The collaboration demos are separate apps, not a bundled feature

Multi person collaboration appears in the project description, and the repository shows how it is treated: as its own set of demo applications rather than a mode of the standard demo. The apps directory lists apps/demo-yjs-react and apps/demo-yjs-vue3 next to apps/demo-html, apps/demo-react and apps/demo-vue3, and the pnpm scripts list matching commands for the two yjs demos.

The test side follows the same split. The root package.json defines separate script sets for the general test run, coverage, and a split coverage runner at scripts/test-coverage-split.js, plus end to end suites for the browser matrix, for performance, and a dedicated yjs run at scripts/run-yjs-e2e.js. The configuration files follow suit: playwright.config.ts, playwright.peer-compat.config.ts, playwright.yjs.config.ts, and vitest.config.mts with vitest.peer-compat.config.mts.

The peer compatibility suite is the interesting one for an adapter library. Editor and adapter versions drift is the most likely integration failure in a setup with four packages, and having a separate Playwright and Vitest configuration dedicated to peer version combinations means the repository checks that combination before a release reaches users. The end to end matrix script names its three projects, chromium-smoke, firefox-smoke and webkit-smoke, and the performance run is gated behind an environment variable so that the expensive pass does not run on every invocation.

What the repository does not show is a production readiness story for collaboration. The presence of two demo apps and a dedicated end to end script tells you the feature is exercised in the repository, not what it costs to run at scale in your own application.

Node version, browser targets and the MIT licence

The runtime requirements are declared in the root package.json rather than being left implicit. The package manager is [email protected], and the engines field pins Node to specific ranges:

  "engines": {
    "node": "^20.19.0 || ^22.13.0"
  },
  "browserslist": [
    "defaults",
    "not IE 11"
  ],

So the project expects Node 20.19 or newer, or Node 22.13 or newer, and it excludes Internet Explorer 11 from its browser targets. If your build pipeline is still on an older Node 18 base image, that field is the first thing to check.

The rest of the tooling is a conventional modern TypeScript stack. Tests run through Vitest with cross-env setting NODE_OPTIONS=--unhandled-rejections=warn, linting uses ESLint with a quiet flag and cache, formatting uses Prettier scoped to packages source and test files, commits are checked by commitlint.config.cjs, and dependency updates are managed by renovate.json. Hooks are installed through husky, and the repository uses Turbo for task orchestration across the workspace.

The licence is MIT, and the README credits it as MIT License (c) 2024-PRESENT cycleccc, pointing at the LICENSE file in the repository root. An MIT licence is a permissive one, which in practice means you can use the editor in a commercial product, but you still owe the copyright notice and licence text to anyone you distribute it with, and that obligation survives the fact that this project is a fork of another MIT licensed editor.

On maintenance, the repository is not archived and the last push was on 2026-10-19. The recent release tags are v6.5.1 on 2026-10-18, v6.5.0 on 2026-09-29 and v6.4.3 on 2026-09-28, so the fork is shipping patch and minor releases at a steady cadence, and the 6.x line is where any new adoption should start.

Editorial conclusion

wangEditor-next is a reasonable pick for teams already using the wangEditor API or the @wangeditor-next package names, since it preserves that surface and keeps shipping releases, with v6.5.1 published on 2026-10-18. It is a poor fit if you need a feature the fork has not yet carried over, or if you want a slate.js editor with a long independent track record, since this project is itself a fork rather than the original upstream. Before you adopt it, install the matching adapter package alongside @wangeditor-next/editor, because the README is explicit that editor and adapter must be upgraded together, and check the v6.0.0 release notes for the video alignment change if you are moving content from v5.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wangeditor-next/wangEditor-next on GitHub