The 1.0 release of @eigenpal/docx-editor replaces the single @eigenpal/docx-js-editor package with five.
@eigenpal/docx-editor-core@eigenpal/docx-editor-react@eigenpal/docx-editor-vue@eigenpal/docx-editor-agents@eigenpal/docx-editor-i18n
This post is about the shape of each package and the rationale for the split. For the line-by-line upgrade path, see the migration guide.
@eigenpal/docx-editor-core
Framework-agnostic. The ProseMirror schema, the OOXML parser and serializer, the plugin host, the headless DocxReviewer, and the layout primitives (page measurement, multi-page rendering, ruler positioning). No React. No Vue. No DOM at the surface.
Dependencies: prosemirror-*, jszip. Around 250 KB minified.
Anything that runs the editor without a host framework reaches for -core directly: server-side review pipelines that round-trip OOXML, edge functions that summarize a document, MCP servers, build-time transforms.
@eigenpal/docx-editor-react
The React adapter. The <DocxEditor> component, the hook set (useHistory, useAutoSave, useFindReplace, useTableSelection, etc.), the UI primitives in /ui (Toolbar, EditorToolbar, pickers, dialogs), and the agent toolkit glue at /agents.
Dependencies: -core, -i18n, React 18+. Around 120 KB on top of core.
If you're shipping a React app, this is the install. -core and -i18n come transitively. Same install line for Next.js, Vite, Remix, Astro.
@eigenpal/docx-editor-vue
The Vue 3 adapter. Same component name, same prop shapes, same plugin contract as the React adapter. Vue idioms at the surface: composables instead of hooks, events instead of callback props, slots instead of render props, kebab-case attributes.
Dependencies: -core, -i18n, Vue 3. Around 115 KB on top of core.
The Vue adapter is the reason -core exists as a published package. In 0.x, React was the only adapter, so -core was implicit inside the monolith. Two adapters force the framework-agnostic layer to graduate from "shared module" to "published package."
The 1.0 adapter ships the editor, composables, dialogs, and plugin-api subpaths. The UI primitive set that React's /ui exposes (toolbars, pickers) is tracked for 1.1.
@eigenpal/docx-editor-agents
The agent toolkit. 14 tools that an LLM can call to drive the editor: read_document, find_text, add_comment, suggest_change, scroll, and the rest. Three transports for those tools:
- Live: drives a mounted
<DocxEditor>so an agent's comments and tracked changes land as the model streams tokens. - Headless:
DocxReviewer.fromBuffer(buf)runs the same tools against OOXML bytes with no DOM. Server-side review, CI pipelines, evals. - MCP: stdio and HTTP server transports exposing the same surface for any MCP-aware client.
Dependencies: -core as a peer (only the headless transport pulls it). Around 80 KB.
Two things justify a separate package. The audience overlaps with but doesn't equal the editor audience: plenty of agent integrations don't render an editor at all, they run DocxReviewer server-side against OOXML bytes. And the license change from AGPL-3.0 to Apache 2.0 was easier to draw at a package boundary than to refactor inside a monolith.
@eigenpal/docx-editor-i18n
Locale strings. Seven languages in 1.0: English, Polish, German, Brazilian Portuguese, Hebrew, Turkish, Simplified Chinese. Pure data. No runtime.
Dependencies: none. Around 50 KB total; per-locale subpath imports (@eigenpal/docx-editor-i18n/pl) code-split to ~7 KB per language.
Shared by both -react and -vue adapters, so it can't live inside either one. Per-locale subpath imports also let apps ship only the languages they support instead of the full 7-locale set.
Why split
Two reasons.
Tree-shaking has limits. The 0.x package's export graph entangled the editor with the MCP server, the agent toolkit, and the parser. Apps installing only the editor still pulled in code from neighbors because their export graph traversed it. Hard package boundaries enforce what tree-shaking is supposed to enforce.
A second adapter needs a real shared layer. Vue support couldn't ship as a feature inside the React package; it needed a peer adapter with a shared dependency. The framework-agnostic surface had to become a published package.
Parity, API reference, license
-react and -vue expose the same surface, and the API reference is generated from the same .d.ts that ships on npm. All five packages are Apache 2.0; the AGPL-3.0 that previously gated the agent toolkit is gone.