Yoopta-Editor's example links all point at a different account than the repository does, and its own feature list contradicts itself

Every source link names a different account than the repository

The repository lives under an organisation-style owner. Not one link in the README points there. The nine example rows in the demos table each carry a live link on the project's own domain and a source link into a personal account, inside a single example application inside this repository. The request to star the project at the end of the motivation section points at that same personal account, and so does the sponsor link. The two badges above the title are a coffee-funding page and a sponsorship page for the same person. So the canonical source for everything the README tells you to read is not the repository you are reading it in, which matters the moment you want to open an issue or check whether a link still resolves to the code you have.

The motivation section sets the tone that makes the rest readable. The author writes that they have integrated rich-text editors into products more times than they would like to admit, and that the story is always the same: wrestling complex APIs, fighting opinionated interface that does not fit the product, hacking around limitations, and writing glue code. It closes with a joke that every star brings them closer to paying for a procedure they are fundraising for, and the joke is the reason the two donation badges sit above the title. So the file is honest about itself in a way most readmes are not, and the link divergence may well be an artifact of a project that moved owners without rewriting its own documentation.

The Material theme ships in one section and is in progress in another

The motivation section promises theme presets for two design systems. The introduction says one of them is available now, as a scoped package, and that the other is in progress. Both statements are in the same file, roughly a screen apart, and the promise appears first. The plugin story has the same shape without being a contradiction: the motivation section counts more than twenty ready-made plugins that ship with the library, while the hosted product section counts more than two hundred community plugins. Two populations, two numbers, and a reader has no way to tell from the file which of them lands in the package they install.

Half the file is a pitch for a hosted product with a scarcity claim

Before the introduction there is a full section promoting a separate hosted application on its own domain, distinct from the documentation site. The pitch is that you describe an app and a model builds it using plugins, that clicking any block edits it inline because the preview is the editor, that you can connect your own API, and that a plugin generator writes a custom block with a live preview and source. It claims two hundred community plugins and real-time collaboration. And it closes with an early-access offer: the first hundred users get lifetime perks. That is a scarcity claim attached to a project whose own README is otherwise a technical document, and it is the second thing a reader sees after two donation badges. Worth noting for anyone deciding what to adopt: the editor and the hosted builder are different products with different data paths, and only one of them is what the MIT licence and the repository actually cover.

Five assistant-tool directories sit at the repository root

The top level contains five directories named after coding assistants, one general agents directory plus four named for specific tools, and two agent instruction files at the root beside them. None of them is referenced by the README, which is entirely about the editor. Some projects commit one of these because their contributors use a particular tool; committing five, plus instruction files, is a statement about the working environment rather than about the product, and it ships in the clone of anyone who installs from source.

Yarn Berry files next to an npm-style workspaces field

The repository ships a Yarn Berry setup: a Yarn cache directory, a Yarn configuration file and a Yarn lockfile. The manifest, meanwhile, declares its workspaces with the npm-style field rather than Yarn's own, and one of the scripts shells out to Yarn to clean before building. Mixing the two is not fatal, since both tools read the npm field, but it means the lockfile and the declaration are being interpreted by different code paths, and a contributor who runs the npm client will not get the resolution the lockfile records. Both the build and the release scripts explicitly exclude the example application from what they compile.

The test surface is broad and the format check is missing

This is where the repository is stronger than its README suggests. The manifest has a plain test command plus non-interactive, watch and interface variants, three separate commands that scope the runner to the plugin, core and mark packages by glob, an integration command that hands off to an end-to-end runner, and a coverage command. Test dependencies include a fake-data generator, a component-testing library in three parts, and an end-to-end driver. Against that, formatting has a write command and nothing else: there is no format-check script, so a pull request can reformat the tree and no job will notice, while the lint path has both a check and a fix variant.

The clean step is a recursive delete over a computed file list

Before every build and before every release, the manifest runs a clean step that finds every directory named dist under the packages tree and removes it recursively. It is the conventional approach for a workspace that builds to per-package output directories, and it is scoped tightly enough to be safe today. It is still a recursive delete driven by a name match rather than by a manifest of known outputs, so the one thing protecting it is that no source directory is currently called dist. The dev command, meanwhile, passes two task names to the task runner in a single invocation, which is the kind of shorthand that tends to outlive its original intent.

Two bundler plugin sets and a minifier plugin from a different era

The build dependencies include five plugins for one bundler covering module resolution, aliasing, replacement, CommonJS interop and minification, and then two separate plugins that convert SVG files into components, one for that bundler and one for a different one, even though the application stack does not appear to use the second. The minifier plugin is the outlier: it is requested at a version two years and around twenty releases behind its siblings in the same list. Test data is generated rather than checked in, which is the right call for a plugin surface this wide.

Editorial conclusion

Fit this if you want Notion-style blocks on Slate and are prepared to own the UI, since the core is headless and the convenience layer is separate packages. Check which of the advertised pieces actually ship: the theme presets are listed as available and in progress in different sections of the same file, and the two plugin counts describe different populations. Build from the repository the manifest describes rather than the account the links name, and expect the example application to be excluded from published builds, which is deliberate but means the demos are not covered by a release. Run the format command yourself, because there is a check for lint and none for formatting.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yoopta-editor/Yoopta-Editor on GitHub