Architecture
Which entry point to import, what each one costs you, and where the boundary between this package and its host actually falls.
The package and the world around it
@liminis/editor is a component, not an application. It has no storage, no file
dialogs, no network, and no opinion about where a document came from. Everything
it needs from its environment arrives through the host seam as an injected
function with a working default, so <Editor> renders in a host that supplies
nothing at all — and a host that supplies everything gets an editor wired into
its own file system, its own clipboard, and its own annotation store.
The arrow that matters is the one from the editor back to the shell. It is not a callback bolted on for one feature; it is how every capability the editor cannot implement for itself is obtained. A host that ignores it still gets an editor, because every one of those services has a default.
Entry points
The package is split so that a consumer pays only for what it imports. The
divide that does the most work is ./headless: it is DOM-free, which is what
lets the Electron main process import it at all.
./headless re-exporting renderC4DiagramToSVG is the reason the two packages
appear together here: a C4 diagram in a document has to render in the main
process too, where there is no DOM, and @liminis/diagrams/server is DOM-free
for exactly that reason.
What this means when you install it
- Importing
.brings React and Lexical. That is the editor. - Importing
./markdownor./annotationsbrings neither. They are ordinary TypeScript over mdast, usable in a script or a server. - Importing
./headlessis a promise enforced by its own doc comment: nothing reachable from it may touchdocument,window, or Lexical. - Lexical is a peer dependency. The host owns the version, because a host that mounts its own Lexical plugins beside this editor must not end up with two copies of it.