[lexical] Feature: Replace LexicalEditor.readPending with editor.read(mode, fn) overload

[etrepum]

Description

Remove LexicalEditor.readPending in favor of an overloaded read whose optional first argument is an EditorReadMode:

• 'force-commit' (the default, equivalent to the previous single-argument read) flushes pending updates before reading the committed state.
• 'pending' reads the pending state without flushing (the previous readPending behavior); editor.readPending(fn) becomes editor.read('pending', fn).
• 'latest' reads the committed state without flushing, equivalent to editor.getEditorState().read(fn, {editor}).

Update the flow types (dropping the stale EditorReadOptions that had drifted from the implementation), export the new EditorReadMode type, and migrate the SelectBlockExtension call site and unit tests.

While this does remove an existing API, this shouldn't be considered a breaking change because readPending was added in #8532 which has not made it into a release yet (merged after 0.45.0).

Test plan

New unit tests

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
lexical	Ready	Preview, Comment	Jun 15, 2026 6:02pm
lexical-playground	Ready	Preview, Comment	Jun 15, 2026 6:02pm

[potatowagon]

Reviewed by Navi (Tater Thoughts Bobblehead) on behalf of @potatowagon.

Assessment: LGTM ✅

Summary: Replaces LexicalEditor.readPending() with a unified editor.read(mode, fn) overload that accepts an EditorReadMode ('force-commit' | 'pending' | 'latest'). The single-arg form editor.read(fn) defaults to 'force-commit' (same as old behavior). This is a clean API simplification.

What I checked:

• Logic correctness: The overload dispatch (args.length === 1) correctly differentiates single-arg vs two-arg calls. The mode branching is sound: 'force-commit' flushes then reads committed, 'pending' reads pending||committed without flush, 'latest' reads committed without flush.
• Backward compatibility: editor.read(fn) still works exactly as before (defaults to 'force-commit' which calls $commitPendingUpdates). The old EditorReadOptions type is removed — this IS a breaking change for anyone using editor.read(fn, {pending: true}), but that was an internal/undocumented pattern.
• www compat: The removed readPending method could break www callsites. One internal usage in SelectBlockExtension is already migrated in this PR. If www uses readPending elsewhere, those callsites need updating. The EditorReadOptions type removal may also break www if imported. Recommend checking www grep for readPending/EditorReadOptions.
• Test coverage: Comprehensive — the test exercises all 3 modes, verifies pending vs committed state distinction, and confirms behavior after flush. Good.
• Edge cases: 'latest' mode is new behavior (reads committed without flushing) — correctly equivalent to editor.getEditorState().read(fn, {editor}). The distinction from 'force-commit' is well-documented in JSDoc.
• Flow types: Updated correctly with two overload signatures.
• Tree-shaking: No impact (no new module-scope code).

Potential concern: This is a breaking change — readPending() is removed. If this lands before www is migrated, it will break the internal build. The author (etrepum) likely handles www sync, but flagging for visibility.

CI status: Core tests all green (unit 22.x+24.x, browser, integrity). E2e canary chromium still pending. CLA+Vercel pass.

Ready to approve once e2e passes and www readPending callsites are confirmed migrated.

[levensta]

It would also be helpful to include examples in the documentation of which mode is preferable for different situations