# HugeRTE: the MIT-licensed fork of TinyMCE

> HugeRTE exists because TinyMCE 7 changed its licence to GPL-or-commercial while earlier versions were MIT, leaving teams that wanted a permissive rich text editor without a supported path. The fork keeps the codebase and the MIT terms, and the price is that you now maintain a fork of an editor whose upstream has moved on.

**hugerte/hugerte** — MIT-licensed fork of TinyMCE, the world's #1 JavaScript library for rich text editing, which switched from MIT to a GPL-or-pay license model in its latest version.

- Repository: https://github.com/hugerte/hugerte
- Website: https://hugerte.org
- Stars: 620 · Forks: 67
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/hugerte-hugerte

## A fork created by a licence change

The README tells the origin story in one long paragraph, and it is unusual to find one stated this plainly.

TinyMCE, the original project, is described as the world's most customizable, scalable and flexible rich text editor, used and trusted by millions of developers. The problem is that TinyMCE changed the licence of version 7 to GPLv2+, or a commercial licence, while it had been MIT for TinyMCE 6 and LGPL for older versions. The README says this creates problems for users and links the discussion on the TinyMCE repository, and that a fork has been created as a result.

The reason to take that paragraph seriously is that a licence change is not a matter of taste. MIT imposes no conditions on redistribution or on how the editor is embedded in a proprietary product, and switching to GPL or a paid licence is a legal decision that every downstream team has to make. A tool that is embedded in a commercial content management system is exactly the case where that decision bites.

The fork was originally named HugeMCE, and the README says it was renamed to HugeRTE before its publication to npm because of potential trademark confusion with TinyMCE. That renaming is a small but telling detail: the fork is deliberately not presenting itself as the original, and it has a name of its own, Hugerte, with the project site at hugerte.org.

## The documentation and the demo live elsewhere

Two things a reader expects in the repository are not there, and both are pointed at explicitly.

The documentation is on a dedicated repository, hugerte-docs, and the README says you can find the documentation there. The demo is on the project website, hugerte.org, which the README describes as the place to quickly play around with the editor.

That arrangement is not unusual for a fork with a large surface area. TinyMCE's documentation is one of the more extensive in the editor world, and a fork that documents itself separately can keep the documentation repository's history and its tooling separate from the editor source.

For someone evaluating the fork, though, the split makes the reading order slightly awkward. The README here is four short sections, so the questions you actually need answered, what the API looks like now, which plugins are supported, and what changed relative to TinyMCE 6, have to be answered in the docs repository or the demo rather than here. That is worth accounting for when you plan the work, because the migration itself is the expensive part of adopting a fork.

The licence position, at least, is unambiguous: the README links an MIT LICENSE.TXT in the repository root, and the repository listing records the licence as MIT.

## A lerna monorepo with yarn workspaces and grunt

The build is inherited from TinyMCE's own, and the README explains why it looks the way it does. In 2019 TinyMCE made the decision to transition their codebase to a monorepo, and for information on compiling and contributing it points at the contribution guidelines.

The top-level package is `hugerte-monorepo`, marked private, with yarn workspaces over `modules/*`, a lerna.json, a Gruntfile.js at the root, and a yarn.lock. The TypeScript build uses project references, with `tsc -b` for a full build and `tsc -b -w` to watch, and there are separate tsconfig files for the shared code and the demo. Linting runs eslint across every module through lerna, with warnings treated as errors:

```
    "ci": "run-s oxide-ci oxide-icons-ci tsc \"hugerte-grunt dev\" \"hugerte-grunt rollup\"",
```

The eslint script runs across every module through lerna with warnings treated as errors. TinyMCE 6 was JavaScript with TypeScript layered on, and the fork is TypeScript as its primary language, which is a meaningful difference for anyone extending the editor rather than just embedding it.

The scripts themselves are the clearest description of the pipeline. `hugerte-grunt` runs grunt against the module's own Gruntfile, `hugerte-rollup` chains a dev build and a rollup step, and `start` is the grunt dev server. The dev script runs the icon and theme builds, the TypeScript build and the grunt dev task in parallel with npm-run-all.

## The oxide packages are built first, and patches are applied after install

Two build details would trip up a first-time contributor, and both are visible in the scripts.

The first is the oxide packages. There are separate script entries for `modules/oxide-icons-default` and `modules/oxide`, with build, ci and start variants for each, and both the dev and ci pipelines run them before anything else:

```
    "dev": "npm-run-all oxide-icons-build oxide-build -p tsc \"hugerte-grunt dev\"",
```

So the icon set and the theme package are compiled as separate packages in the workspace, and the editor build depends on their output. That is a monorepo with real package boundaries, not a single project with folders.

The second is `postinstall`, which runs `patch-package`, and there is a `patches` directory in the repository. Patches applied at install time are how a fork carries local modifications to its dependencies, and it is worth knowing they are there before you wonder why a fresh install behaves slightly differently from a clean upstream one.

The CI scripts are built from the same parts, with `ci` chaining the oxide builds, the TypeScript build and the grunt dev and rollup tasks, and `ci-all` running eslint in parallel with that. The `build` script is the publish path, combining the oxide ci builds and the grunt task.

## Tests run in a headless browser and a real one

The test setup uses Mozilla's Bedrock, and the scripts show both halves of it.

The main test script runs the headless suite and then the browser suite in sequence:

```
    "test": "run-s headless-test browser-test",
```

The headless target is `grunt headless-auto`, the browser target is `grunt browser-auto`, and there is a manual variant of each for running the tests with a visible browser. There is also a Firefox variant of the headless run, which passes the browser choice through to Bedrock:

```
    "headless-test-firefox": "grunt headless-auto --bedrock-browser=firefox-headless",
```

and the Bedrock invocation itself carries a custom routes file, so the test server serves the editor's own routes:

```
    "bedrock": "bedrock --customRoutes modules/hugerte/src/core/test/json/routes.json",
```

The `test-one` script exists for the common case of running a single test file, compiling first and then invoking bedrock directly in chrome-headless with a file filter.

The practical implication is that a contributor needs a browser to work on this project, not just Node. The headless mode exists so that the suite can run without one, but the browser mode is part of the default test run, which tells you that the editor is tested in the environment its users will actually be in.

## A 1.0.x line that tracks a fork, not an upstream

The release history is the part that needs the most careful reading, because the version numbers do not correspond to TinyMCE's.

The recent releases are v1.0.14 from 2026-09-05, v1.0.13 from 2026-09-01 and v1.0.12 from 2026-06-30. TinyMCE is on its seventh major version, and the fork is on its first, which tells you the fork restarted the numbering rather than continuing TinyMCE's. The repository also carries a versions.txt file and a build.properties, the two places where a version like this normally lives in the TinyMCE tree.

The repository is not archived and the last push was on 2026-10-08, so the fork is being worked on. The primary language is TypeScript, and the topic list is the editor vocabulary: contenteditable, editor, javascript, rich-text-editor, wysiwyg, wysiwyg-html-editor.

The honest assessment of a fork at this stage is that it is a different product with a shared history. The code, the plugin ecosystem and the documentation start from a particular upstream release, and everything upstream has done since then is absent unless the fork has ported it. A team that has already built against TinyMCE 6 gets a close match. A team starting fresh gets an editor whose feature set is a snapshot, with a maintainer group that has to keep porting.

## Conclusion

HugeRTE fits a team that needs a mature WYSIWYG editor under MIT terms and is prepared to track a fork rather than an upstream, and whose content model and plugins already match TinyMCE 6. It is the wrong choice for a team starting a new application in 2026, because the fork has diverged from a TinyMCE 7 feature set and the upstream will not merge back. Verify first which upstream release the fork was cut from, which TinyMCE plugins your application depends on, and whether the TinyMCE 7 licence terms would in fact have been acceptable to you, since that is the only question that decides this.

## FAQ

### Why does HugeRTE exist?

Because TinyMCE changed the licence of TinyMCE 7 to GPLv2+ or a commercial licence, while it had been MIT for TinyMCE 6 and LGPL for older versions. The fork was created to keep the editor under MIT terms, and the README links the upstream discussion of the problem.

### Is HugeRTE under the MIT licence?

Yes. The README links an MIT LICENSE.TXT in the repository root, and the repository is recorded as MIT licensed. The fork was originally named HugeMCE and was renamed to HugeRTE before publication to npm over potential trademark confusion with TinyMCE.

### Where is the HugeRTE documentation?

On a separate repository, hugerte-docs, which the README points to. The editor itself can be tried on the project website at hugerte.org.

### How do I build HugeRTE from source?

It is a yarn workspaces monorepo over modules/* managed with lerna, with grunt doing the bundling and TypeScript project references for the type build. The dev script runs the oxide icon and theme package builds, the tsc build and the grunt dev task together, and a postinstall step applies patches with patch-package.

### How are the HugeRTE tests run?

With Mozilla's Bedrock. The test script runs the headless suite and then the browser suite, there is a Firefox variant of the headless run, and the bedrock script passes a custom routes file from the editor's own test directory. A test-one script compiles and runs a single test file in chrome-headless.

## Sources

- [hugerte/hugerte on GitHub](https://github.com/hugerte/hugerte)
- [License: MIT](https://github.com/hugerte/hugerte/blob/main/LICENSE)
- [Project website](https://hugerte.org)
- [README](https://github.com/hugerte/hugerte/blob/main/README.md)
- [Releases](https://github.com/hugerte/hugerte/releases)

---

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