Skip to content

feat(text-editor): deprecate legacy image handling in favor of inlineImages#4181

Merged
FredrikWallstrom merged 1 commit into
mainfrom
refactor/deprecate-legacy-image-handling
Jul 10, 2026
Merged

feat(text-editor): deprecate legacy image handling in favor of inlineImages#4181
FredrikWallstrom merged 1 commit into
mainfrom
refactor/deprecate-legacy-image-handling

Conversation

@FredrikWallstrom

@FredrikWallstrom FredrikWallstrom commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

The inlineImages prop now owns the whole inline-image lifecycle — paste, upload, storage format, and URL resolution — so the older event-based API it replaces is on the way out.

Marks these as deprecated, all pointing at inlineImages:

  • imagePasted event and its ImageInserter interface (the manual paste-handling hook)
  • metadataChange event and its EditorMetadata interface
  • imageRemoved was already deprecated; its notice pointed at metadataChange, which is now also going away, so it's repointed at inlineImages too

No runtime behavior changes — this is JSDoc plus the regenerated API report.

Summary by CodeRabbit

  • Documentation
    • Updated developer-facing deprecation notes for legacy image and metadata-related editor events.
    • Marked older image/metadata interfaces as deprecated and clarified that inline image handling is managed via the inlineImages prop.
    • Clarified that deprecated metadata/link behavior has no direct replacement yet and is planned for future removal.
  • Chores
    • Added maintenance guidance comments to support future event removal.

@FredrikWallstrom FredrikWallstrom requested a review from a team as a code owner July 10, 2026 07:18
@coderabbitai

coderabbitai Bot commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Review limit reached

@FredrikWallstrom, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 48 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 65103c44-82ef-4cae-bb5c-054c7f7b0a4a

📥 Commits

Reviewing files that changed from the base of the PR and between f50a4b8 and 2f59d50.

⛔ Files ignored due to path filters (1)
  • etc/lime-elements.api.md is excluded by !etc/lime-elements.api.md
📒 Files selected for processing (3)
  • src/components/text-editor/prosemirror-adapter/prosemirror-adapter.tsx
  • src/components/text-editor/text-editor.tsx
  • src/components/text-editor/text-editor.types.ts
📝 Walkthrough

Walkthrough

Changes

Text editor deprecation documentation

Layer / File(s) Summary
Update image API deprecation notices
src/components/text-editor/text-editor.tsx, src/components/text-editor/text-editor.types.ts, src/components/text-editor/prosemirror-adapter/prosemirror-adapter.tsx
JSDoc for image events and interfaces now directs consumers to inlineImages, while an adapter comment documents continued image-cache eviction after deprecated metadata events are removed. Types and runtime behavior are unchanged.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Possibly related PRs

Suggested labels: released

Suggested reviewers: adrianschmidt, jgroth

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: deprecating legacy text-editor image handling in favor of inlineImages.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch refactor/deprecate-legacy-image-handling

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions

Copy link
Copy Markdown

Documentation has been published to https://lundalogik.github.io/lime-elements/versions/PR-4181/

@FredrikWallstrom FredrikWallstrom force-pushed the refactor/deprecate-legacy-image-handling branch 2 times, most recently from 054cce5 to 88bc9eb Compare July 10, 2026 07:33
Comment thread etc/lime-elements.api.md
Comment on lines 1068 to 1282
@@ -1282,7 +1282,7 @@ interface Image_2 {
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could be wrong, but the new functionality was only about handling images. This interface also handles links. I'm not sure if we should deprecate it yet?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

John and I talked this through. Honestly, EditorMetadata wasn't very well thought through when it first landed, and nothing at Lime Technologies actually consumes it. Since it's alpha, we're comfortable deprecating it now — and if we ever want it back, we can just un-deprecate it. We can design a proper interface for this later if a real need shows up.

On links specifically: I'm not sure consumers actually need to know when a link is pasted. If it turns out they do, a dedicated linkPasted event would probably be cleaner than folding it into metadata.

@john-traas john-traas self-assigned this Jul 10, 2026
john-traas
john-traas previously approved these changes Jul 10, 2026
@FredrikWallstrom FredrikWallstrom force-pushed the refactor/deprecate-legacy-image-handling branch from f50a4b8 to 2f59d50 Compare July 10, 2026 12:00
@FredrikWallstrom FredrikWallstrom enabled auto-merge (rebase) July 10, 2026 12:00
@FredrikWallstrom FredrikWallstrom merged commit ee61edd into main Jul 10, 2026
18 checks passed
@FredrikWallstrom FredrikWallstrom deleted the refactor/deprecate-legacy-image-handling branch July 10, 2026 12:16
@lime-opensource

Copy link
Copy Markdown
Collaborator

🎉 This PR is included in version 39.44.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants