easy-email-editor's own table says the open-source version is Chrome-only, and its quick-start snippet ends mid-function

The comparison table says Chrome only and no React 19

The open-source README carries a seven-row table comparing the free version with the commercial one, and the first two rows are the ones to read. Browser compatibility: the open-source version supports Chrome only, while the paid version works across browsers by using an iframe. That second half is the informative part, because rendering inside a frame is a workaround for exactly the fragility the open-source version exposes. The next row is language support: React 19 is marked as not supported in the open-source version and supported in the paid one. Responsive design is likewise listed as unavailable for free. Everything after that, from the interactive blocks to migration from another editor, is feature gating rather than a capability the free version does badly.

The getting-started snippet stops at a function declaration

The code sample in the getting-started section imports three symbols from the core package, two from the editor package and two from the extensions package, then imports three stylesheets, then builds an initial-values object, and then ends like this:

export default function

There is no parameter list, no body, no closing brace and nothing after it. So the one worked example in the file cannot be pasted into an editor, and the three imported symbols, two of them types and one of them a layout component, are never used in the visible text. The sample also imports stylesheets from a build-output path inside the editor and extensions packages, so it assumes those packages have been compiled, and the third stylesheet comes from a theme package that the install command on the line above does not mention.

The install command says one package manager and the lockfile says another

The getting-started block gives one shell line, and it is a Yarn-and-npm style invocation with a shell prompt in front of it:

$ npm install --save easy-email-core easy-email-editor easy-email-extensions react-final-form

The repository, however, ships a pnpm lockfile and pins its package manager to a specific version with a full content hash, which is better practice than most projects manage. So the documented command and the recorded resolution come from different clients. The line also installs a fourth package that the sample never imports directly, while omitting the theme package whose stylesheet the sample does import, so neither following the prose nor following the code gives you a complete dependency list.

The root manifest depends on an email provider, a CDN and an analytics SDK

The published root manifest is not the editor. Its runtime dependencies include a commercial transactional email provider's client, a cloud image service client, a product analytics SDK, a file-saving helper, a template engine and a localisation helper, plus the release tool itself as a runtime dependency. Those all look like demo-application concerns, but they sit in the root package rather than in the demo's own manifest, so anyone installing the workspace root pulls them. One of them is a types package listed as a runtime dependency rather than a development one. The manifest also carries no version field, no private marker, no licence field and no workspaces field, even though a release-tool configuration file and a pnpm lockfile are both present at the root.

One script points at a directory that is not in the repository

The scripts are built out of directory changes rather than workspace filters: one command changes into the core package and builds it, another does the same for the editor package, another for the extensions package, and the top-level build chains all three in sequence. Alongside those sit a development command and a demo build command that both change into the demo directory, and a second demo build command that changes into a directory for a Next.js demo which does not appear anywhere in the repository's top-level listing. There is also no test script, no lint script, and no clean script, despite an editor plugin for a linter being present as a development dependency and no linter configuration file existing at the root.

Two readme files, and a workflow file that never runs

The top level contains both README.md and readme.md, differing only in the case of the extension. On a case-insensitive checkout those two paths are the same file; on a case-sensitive one they are two files, and only one of them is the one GitHub renders. The same kind of near-collision appears elsewhere: a file named github-actions-demo.yml sits at the repository root rather than in the workflows directory, where a continuous integration system looks for it, so whatever it was written to demonstrate is not actually running as a workflow. A deployment configuration file and an api directory at the root point at a hosted serverless deployment rather than a static site, which does not match a project whose demos are static pages.

The logo points at a third-party domain with a tracking parameter

The header of the README is assembled from centred anchors, and the first one, labelled as the project logo, resolves to an unrelated-looking domain with a campaign parameter appended. The three badges beside it are labelled for a framework, for the markup language and for package size, and the third resolves to the home page of the programming language rather than to any package size report, so the label and the destination disagree. The introduction's table has a header for a video and an empty body cell, which is an embedded video that did not survive the format. And the free email templates are hosted under a different organisation entirely from the repository, which is the third naming namespace this project spans.

Editorial conclusion

Fit this if you are targeting one browser, building email in React, and willing to own image storage yourself, since the library hands you an upload hook and no endpoint. Read the comparison table before you commit, because responsive design and React 19 are both listed as paid and the paid version reaches cross-browser support by rendering inside a frame, which tells you the open-source DOM strategy is the fragile one. Install with the package manager the lockfile uses rather than the one the getting-started block shows, and finish the truncated example from the published API docs before you wire it up.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zalify/easy-email-editor on GitHub