Lexical is an extensible text editor framework that provides excellent reliability, accessibility and performance.
by facebook5 of 6 standards met
Description Previously, it was possible to enter invalid characters in the text of an unlinked AutoLinkNode, which made the link invalid. The fix activates parsing of valid links in AutoLinkNode if they are marked as unlinked Test plan Before https://github.com/user-attachments/assets/d3100cb7-f297-4d35-80fd-84b45f9536af After https://github.com/user-attachments/assets/16113a8d-c484-4d98-b23b-77bde6c0884d
Description Currently, lexical has some utility functions that return an instance of a node class. There is also a Node Replacement mechanism that allows you to replace any node with an extended child class. If a replacement is registered, any utility function that creates a new node replaces the base class with the replacement class, but TypeScript always shows one type of base class, which can lead to some errors. Here is an example In such a situation, a workaround is to use a rough type casting using Or a more exotic way is to redefine the type at the module level A safe way to solve the type problem is to use type guards But this approach is unnecessarily verbose. If node replacement is used in the editor, the user knows that the function will return the replaced instance anyway (if it is known that the function creates it) Possible solution A possible flexible and type-safe solution would be to define such functions as generics that constraint the provided type to the expected class. Impact This will improve the developer experience and those using lexical and its packages with nodes, and eliminate the need for unsafe type conversions and verbose checks.
Repository: facebook/lexical. Description: Lexical is an extensible text editor framework that provides excellent reliability, accessibility and performance. Stars: 23021, Forks: 2093. Primary language: TypeScript. Languages: TypeScript (72.6%), JavaScript (24.7%), CSS (1.8%), MDX (0.7%), HTML (0.1%). License: MIT. Homepage: https://lexical.dev Latest release: v0.41.0 (3d ago). Open PRs: 22, open issues: 534. Last activity: 11h ago. Community health: 87%. Top contributors: trueadm, zurfyx, acywatson, etrepum, fantactuka, thegreatercurve, ivailop7, tylerjbainbridge, potatowagon, Sahejkm and others.
TypeScript
Last 12 weeks ยท 90 commits
Description This PR fixes an issue where SVGs inserted without explicit and attributes (such as dimensionless SVGs or base64 data URIs) would visually collapse to in the editor. The Problem When a dimensionless SVG or a base64 SVG string is parsed: 1. The browser reports and as . 2. The constructor defaults missing dimensions to . 3. In the React layer (), the previous fallback logic relied on a fragile check that failed for base64 data URIs. 4. Because the intrinsic dimensions were , the component rendered with inline styles, making the node invisible and unselectable. The Fix I pivoted from a global fallback to a Surgical SVG Fallback to maintain compatibility with Lexical's existing E2E test suite: Updated the logic to identify SVGs using both file extensions and prefixes. Preserved CSS Inheritance: Standard images (JPG/PNG) continue to return for dimensions. This ensures that existing E2E tests (which rely on specific HTML snapshots for standard images) remain green and global CSS remains in control of responsive sizing. SVG Math Safety Net: For SVGs specifically, if no intrinsic dimensions are found, the logic now falls back to the node's . This ensures a visible bounding box is rendered, allowing the user to see, select, and resize the image. Fixes #7511 Test Plan New Test: Added -> "Dimensionless SVG renders with a visible bounding box instead of collapsing". This verifies that a base64 encoded SVG without attributes renders with a width/height > 0. Regressions: Verified that standard image snapshots (e.g., the "Yellow Flower" JPG in ) still receive to satisfy existing Playwright assertions. Local Verification:** Ran and confirmed all 600+ tests pass.
Leading and trailing whitespaces inside formatted text are already moved outside the formatted region to ensure correct markdown. But if the formatted text only contain whitespace, then we end up with formatting for the empty string, e.g. for a bold whitespace. So we need to skip the formatting in these cases. The previous attempt at fixing this in #7400 used html entities to escape leading/trailing whitespaces inside formatted texts, but this breaks commonmark. Example that breaks when using html entities: https://spec.commonmark.org/dingus/?text=bold%20space%20with%20adjacent%20text%3A%20%26%2332%3Badjacent%0A%0A Reverts #7400 Closes #7575 Test plan Automated test in Before After