@schnsrw/docx-js-editor@1.1.7

Patch Changes

• Toolbar polish: tighter color-strip indicator under font-color / highlight / border buttons (was 16×4 px overlapping the icon, now 18×3 px sitting cleanly below with a 1 px breathing gap). Matches Google Docs' visual rhythm and clears the "chunky highlight strip" feedback from the 2026-06-17 demo walkthrough.

@schnsrw/docx-js-editor@1.1.6

Patch Changes

• embed-runtime: forward DocxEditor parse / load errors to the host via transport.sendError(parse_failed) so hosts can swap the iframe for a friendly fallback instead of letting the SDK's own red error UI surface to end users.

@schnsrw/docx-js-editor@1.1.5

Patch Changes

• embed-runtime: bundle the tailwind-compiled editor CSS (dist/styles.css) into dist/embed/embed-runtime.css so the iframe's <link rel="stylesheet"> serves the full editor stylesheet. Without this, every toolbar button stacked vertically with no layout and the canvas painted unstyled.

@schnsrw/docx-js-editor@1.1.4

Patch Changes

• embed-runtime: hide all chrome (toolbar, menubar, panel rail, status bar, ruler, zoom) and lock read-only in preview mode; toggle on viewMode commands.

@schnsrw/docx-js-editor@1.1.3

Patch Changes

• embed-runtime calls transport.sendReady() after sendHello(). The
  host (CasualEditorIframe) only sends its hello inside onEditorReady;
  without an eager casual.ready from the iframe, the handshake
  deadlocked and bytes never loaded.

@schnsrw/docx-js-editor@1.1.2

Patch Changes

• Add platform: 'browser' to the embed-runtime tsup config so esbuild
  picks the browser variant of dual-target deps. 1.1.1 bundled deps but
  still grabbed import { ... } from 'crypto' from the Node fork of
  nanoid, which the browser can't resolve. Runtime now lands clean.

@schnsrw/docx-js-editor@1.1.1

Patch Changes

• Bundle React + ProseMirror + all deps into the embed-runtime instead
  of leaving them as external imports. The previous build expected the
  consumer to provide an importmap; consumers like Casual Drive that
  embed via <iframe src="…/embed.html"> had no way to do that, and
  the bare import 'react' failed at runtime in the browser.

  The runtime now ships ~2.8MB self-contained (cached after first load).

@schnsrw/docx-js-editor@1.1.0

Minor Changes

• c702b94: Ship the SDK iframe-delivery architecture (Phase 1 of doc 16).

  The existing <CasualEditor> direct-mount stays — no breaking change.
  Adds a new <CasualEditorIframe> component that renders the editor
  inside a same-origin iframe instead of co-mounting it into the host's
  React tree. CSS isolation, React-runtime isolation, and the
  React.Activity init-crash workaround all go away when consumers
  switch from direct-mount to iframe.

  What the consumer-facing API looks like

  import { CasualEditorIframe } from '@schnsrw/docx-js-editor';
  
  <CasualEditorIframe
    fileSource={driveFileSource}
    docId={file.id}
    viewMode="preview"           // or "editor"
    embedBasePath="/embed/docs"   // defaults to /embed/docs
    onSelectionChanged={…}
    onError={…}
  />;

  No iframe, no postMessage, no EmbedTransport wiring in the consumer.
  The wrapper owns all of that internally.

  Build artifacts

  Three new files in dist/embed/:

  • embed-runtime.mjs — self-contained ESM bundle that boots the editor
    inside the iframe.
  • embed-runtime.css — sibling stylesheet.
  • embed.html — minimal HTML document the iframe loads.

  Consumers copy these into their public dir at embedBasePath (default
  /embed/docs). A Vite plugin (@schnsrw/docx-js-editor/vite-plugin)
  that does the copy ships in v1.1.x; for v1.1.0 the contract is a
  two-line postinstall script:

  mkdir -p web/public/embed/docs
  cp node_modules/@schnsrw/docx-js-editor/dist/embed/* web/public/embed/docs/

  Wire protocol additions

  • casual.command.set.viewmode — live preview ↔ editor toggle.
  • casual.error — editor → host fatal-error signal.

  Both are documented in docs/internal/13-iframe-protocol.md (extended)
  and docs/internal/16-sdk-iframe-architecture.md (new design doc).

  What's not in this minor

  • The full ref API (flushSave, getSelection, signing.start) — ships
    in v1.1.x once Drive proves the wire end-to-end.
  • The Vite plugin — v1.1.x.
  • The CasualSheets mirror — separate publish of
    @schnsrw/casual-sheets@0.5.0.
  • Preview-mode chrome hiding inside the iframe — currently surfaced as
    a data-view-mode attribute on the embed root; v1.1.x wires the
    attribute to component-level chrome toggles.

@schnsrw/docx-js-editor@1.0.1

Patch Changes

• Fix format-converter.worker.ts bundling. The published dist/
  referenced new Worker(new URL('./format-converter.worker.ts', import.meta.url)) but didn't ship the .ts source — any consumer
  whose bundler honours the new Worker(new URL(...), import.meta.url)
  pattern at build time (Vite, modern webpack with worker-plugin, esbuild's
  bundler) errored with "Could not resolve entry module
  .../format-converter.worker.ts" before the consumer's app could even
  import a single editor symbol.

  tsup.config.ts now adds format-converter.worker as its own entry
  (emits dist/format-converter.worker.mjs + .cjs as siblings to the
  main chunks) and rewrites the runtime URL in the compiled
  format-converter chunk from ./format-converter.worker.ts to
  ./format-converter.worker.mjs via a renderChunk plugin. Consumers'
  bundlers resolve the URL correctly because the file exists in
  node_modules at the path the URL points at.

  Existing consumers (Casual Drive in particular) can drop the
  Vite-transform workaround that rewrote the worker construction to a
  no-op once they bump to this version.

  See #4 for the original report.

@schnsrw/docx-js-editor@1.0.0

Major Changes

• 56bdee8: Rename published scope from @eigenpal/docx-js-editor to @schnsrw/docx-js-editor.

  This fork has diverged substantially from upstream and now ships under a scope the
  maintainer owns on npm. Imports should switch from @eigenpal/docx-js-editor to
  @schnsrw/docx-js-editor — every other export shape, type, and subpath is
  unchanged. Workspace internals (@eigenpal/docx-core, @eigenpal/docx-editor-vue)
  remain on the old scope; they're private and not published.