[gohabereg]

Why

First implementation step of the editor-destroy OpenSpec change (spec PR #195, the base of this one). Adds the editor teardown lifecycle and the API changes it needs; the adapters/UI/plugins side follows in a stacked PR.

What Changes

• Core#destroy(): plugins in reverse construction order (destroy?.() + PluginRegistry.unregister), then UndoRedoManager, SelectionManager, BlockRenderer, the adapter (destroy?.(), made required in the next PR along with DOMAdapters.destroy()), and last ToolsManager. Each step runs through a helper that logs and continues. Services resolved in initialize() are recorded in #services, so teardown never constructs one. A second call is a no-op because instances and services are cleared. use()/initialize() throw afterwards. Core's onModelUpdate model listener goes through a controller that destroy() aborts, so a model the integrator kept no longer reaches the callback after teardown.
• Interrupted initialize() rejects with a DOMException named AbortError instead of booting the document or dispatching core:ready. ToolsManager owns an AbortController that its destroy() aborts. Its preparation queue checks that signal before and after each tool's prepare(). Tools still queued are never prepared, and a tool whose prepare() settles after destroy is never created, registered or announced with ToolLoaded. A prepare() already running can't be interrupted, because it takes no signal, so its result is dropped.
• EditorJS#destroy() delegates to Core. The bundle attaches reportUnlessAborted() to its ready promise: AbortError is ignored and other init errors are logged, so nothing is reported as an unhandled rejection. Awaiting isReady still rejects.
• BlockRenderer keeps each block's tool instance and destroys it on block removal and on teardown. A render that settles after teardown dispatches nothing.
• Tool contracts: optional destroy() on BlockTool/InlineTool, called once per instance by its owner:
  • Block tools: BlockRenderer owns each per-block instance.
  • Inline tools: InlineToolFacade.create() returns one cached instance per tool, shared by formatting, selection, validation and the inline toolbar. None of those consumers destroys it. The facade's new destroy() does, once and only if the instance was ever created, and ToolsManager.destroy() calls it for every inline tool, logging a throwing hook and moving on to the next.
• Listeners through AbortController: onUpdate/onCaretUpdate subscribe through their own controller (signatures unchanged). UndoRedoManager, SelectionManager and BlockRenderer abort one controller each. BlockToolAdapter owns its controller and exposes protected signal to subclasses. EditorJSModel's typed addEventListener overloads accept options.
• OpenSpec: the spec revisions behind these fixes (D3, D4, D7, and the new core and sdk scenarios) are in docs(openspec): propose editor-destroy #195 and merged into this branch. This PR only checks off their tasks.

Verification

• Full workspace build, lint and tests pass.
• Mutation testing on every line this PR adds (Stryker scoped to the diff, -w): all mutants killed in core, and in sdk/editorjs via an ad-hoc run (those packages have no Stryker config). model changes are type-only. The packages' own yarn test:mutations pass.
• Tests cover:
  • teardown order, including inline tools after the adapter; error logging; idempotency
  • destroy before and during initialization, including tools still queued and a prepare() that settles after destroy
  • late renders
  • tool instance destruction: each shared inline instance destroyed exactly once, and never by SelectionManager or ToolsManager validation
  • the AbortError handling, including that it is not left unhandled
  • onModelUpdate after destroy

Notes

• ToolsManager's inline-tool render check is pinned by tests as-is; removing it is tracked on the board ("Remove inverted inline tool render check in ToolsManager").
• The integration tasks (real DOM, several editors per page) are covered by the e2e suite in feat: implement destroy() in adapters and plugins #207.

Stack

1. docs(openspec): propose editor-destroy #195 spec
2. This PR
3. feat: implement destroy() in adapters and plugins #207 adapters, plugins, e2e tests and the archive (stacked on this one)

🤖 Generated with Claude Code

[github-actions]

Unit Tests

Package	Coverage	Delta
@editorjs/shortcuts-plugin	100%	0% ⚪️
@editorjs/collaboration-manager	85.81%	0% ⚪️
@editorjs/clipboard-plugin	66.66%	0% ⚪️
@editorjs/dom-adapters	86.95%	0% ⚪️
@editorjs/editorjs	100%	0% ⚪️
@editorjs/ot-server	20%	0% ⚪️
@editorjs/model	98.48%	0% ⚪️
@editorjs/core	77.02%	+3.88% 🟢
@editorjs/model-types	N/A	N/A

Mutation Tests

Package	Mutation score	Dashboard URL
@editorjs/shortcuts-plugin	No files to mutate found.
@editorjs/clipboard-plugin	No files to mutate found.
@editorjs/dom-adapters	No files to mutate found.
@editorjs/model	NaN%	Dashboard
@editorjs/collaboration-manager	No files to mutate found.
@editorjs/core	74.64% 🟡	Dashboard

[neSpecc]

destroy() never releases the onModelUpdate listener registered in the constructor.

It is this.#model.addEventListener(EventType.Changed, ...) with no signal, and teardown does not call removeEventListener for it. The other listeners in this PR are tied to an AbortController and aborted here. This one stays for as long as the model is reachable.

destroy() does not mutate the model, so the callback does not run during teardown itself. It does run on any later change: something still holding api, or a collaboration op that arrives after unmount. The integrator passed that callback and then unmounted, so it fires into a tree that is already gone.

Abort it from here, same as the service listeners.

[Reversean]

Check cancellation inside ToolsManager before post-prepare() validation. If destroy() runs while an inline tool is preparing, tool.create() and ToolLoaded still run after teardown, before this guard rejects readiness.