# Lexxy brings a Lexical editor into a Rails app

> Lexxy is a rich text editor for Rails that runs on Meta's Lexical and keeps the canonical HTML that Action Text already stores. It suits teams that want a different editing experience without moving stored documents, and it is a poor fit for applications that are not Action Text based.

**basecamp/lexxy** — A modern rich text editor for Rails.

- Repository: https://github.com/basecamp/lexxy
- Website: https://lexxy.dev
- Stars: 1,250 · Forks: 122
- Language: JavaScript
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/basecamp-lexxy

## A front end swap rather than a storage migration

Lexxy is a rich text editor for Rails, published from the basecamp repository as a Ruby gem (the top level holds lexxy.gemspec) and as a JavaScript package. The audience is narrow on purpose: applications that already keep rich text in Action Text and want a different editing surface. The README states that Lexxy works with Action Text, generating the same canonical HTML format it expects for attachments. That single sentence is the architecture.

Under the editor, Lexxy is built on Lexical, the text editor framework from Meta. So the stack is Rails on the server, Action Text as the persistence contract, and a JavaScript editor engine in the browser. Nothing in the project description suggests a server side rendering path or a plugin API of its own.

The alternative to adopting Lexxy is keeping the editor that comes with Action Text. The difference in approach is therefore narrow and worth naming precisely. The stored representation stays the same, so existing rich text records do not need conversion, while the editing experience gains markdown shortcuts, prompt based mentions, and in editor attachment previews. Teams that have already invested in Action Text attachments gain the least from a swap. Teams whose users complain about a bare editor gain the most.

## Real paragraph tags instead of a canvas of styled divs

The feature list puts HTML semantics first: paragraphs are real p tags, as they should be. That is a structural choice, not a cosmetic one, and it is the kind of detail that determines how screen readers, find in page search, and plain text extraction treat a document. The README also states that the editor is designed with accessibility in mind, and the documentation lives at a dedicated accessibility page under lexxy.dev/docs.

What the README does not document is the size of that accessibility commitment. There is no statement about conformance level, no list of tested screen readers, and no key binding table. An accessibility page exists, but its contents are not reproduced in the project overview, so how far the editor goes beyond semantic markup cannot be established from what the project publishes here.

The practical consequence is that accessibility here should be verified rather than assumed. If your acceptance criteria include a formal audit, the accessibility documentation page is the place to start reading, and a manual pass with your own assistive technology setup is the only reliable check.

## Markdown shortcuts, paste reformatting, and live code highlighting

Markdown support arrives as two things: keyboard shortcuts and auto-formatting on paste. The shortcut layer is what lets an experienced user type a heading or a list without leaving the keyboard, and the paste path is what rescues content copied from a code review, a terminal, or a chat window where the source formatting is noise. Both behaviours are listed as features, and neither is documented in detail in the project overview, so the exact trigger characters and the exact set of supported rules are not stated.

Code syntax highlighting is described as real time, which means highlighting happens in the editor as the user types rather than when the document is rendered. Combined with paste auto-formatting, this makes the editor feel closest to a code aware writing tool rather than a general word processor.

The same source is less specific about behaviour in failure cases. What happens to a partial markdown sequence, whether paste into a code block is treated differently from paste into a paragraph, and whether the shortcuts are configurable are all open questions. If your users paste code often, these are the details to test with real content before standardising on the editor.

## Prompts are pluggable, and filtering is where the work sits

Configurable prompts are the feature that goes furthest beyond a plain editor. The README describes support for mentions and other interactive prompts, and it is specific about the underlying problem: there are multiple loading and filtering strategies. That phrasing matters. A mention field that works on a fixed list of a few dozen people is a different piece of software from one that queries a remote source and narrows results as the user types, and an editor framework has to support both.

The project does not enumerate those strategies in the overview, and the configuration surface is not shown. It is therefore not possible to tell from the project description whether strategies are declared in JavaScript, in a server rendered attribute, or in data attributes, or whether a custom remote source is a supported extension point.

That is a documentation gap rather than a defect, and it is the one most likely to matter for a team that wants mention support in a real application. Reading the documentation site is the way to settle it, and a small spike that drives a mention field against a slow or failing endpoint would tell you more than the feature list.

## Attachment previews have to match what Action Text expects

The editor can preview attachments such as PDFs and videos in place, and it claims to work with Action Text by generating the same canonical HTML format that Action Text expects for attachments. These two claims belong together. A preview is a read side affordance, but what the editor ultimately submits is markup that Action Text has to accept and store, and any divergence between what the preview shows and what the server stores becomes a data problem rather than a rendering problem.

Because Lexxy writes the canonical format, an application that swaps editors keeps its existing attachment markup. That is the main upgrade path in practice, and it is also the main risk area: an editor that stores the same format but presents attachments differently can still change what users see after they save.

The project overview does not enumerate the attachment types that can be previewed beyond PDFs and videos, nor does it state which Active Storage variants are used. Since the JavaScript package lists @rails/activestorage among its development dependencies, Active Storage is clearly part of the development environment, but the exact preview pipeline is not documented in the overview.

## The JavaScript side ships as two Rollup bundles

The npm side of Lexxy is a small, conventional package. The manifest names the package @37signals/lexxy, declares the entry point as an ES module, and exports a second entry point for helpers. The exported paths and module type are visible in the manifest:

```json
  "name": "@37signals/lexxy",
  "version": "1.0.1",
  "module": "dist/lexxy.esm.js",
  "type": "module",
  "exports": {
    ".": "./dist/lexxy.esm.js",
    "./helpers": "./dist/lexxy_helpers.esm.js"
  },
```

A bundler friendly package with a distinct helpers export, and a browser support floor declared through a browserslist entry of baseline 2023 with dead browsers excluded. That floor is a useful commitment: it tells you the editor expects reasonably current browsers, so an old Internet Explorer or legacy Edge deployment is out of scope.

The build and test commands are equally plain, and they are the scripts a contributor would actually run:

```json
    "build": "rollup -c",
    "lint": "eslint",
    "test": "vitest",
    "test:browser": "npx playwright test --config test/browser/playwright.config.js",
```

Unit tests run under Vitest and browser tests run under Playwright, with the browser configuration kept in a separate file. The project also ships a rollup config for the npm distribution, so the published artefact and the Rails asset pipeline build are produced by different config files on purpose.

## Development workflow: linking a local Lexical and a three engine test run

For contributors, the README points at a script for working with a development version of Lexical:

```bash
bin/link-to-local-lexical
```

This exists because the editor depends directly on the framework from Meta, and the project wants contributors to be able to test against unreleased Lexical changes. The top level of the repository also carries a Procfile.dev for a development server and a Rakefile, which is the conventional Rails layout.

Browser coverage is broad but not open ended. The scripts include separate commands for Chromium, Firefox, and WebKit, each pointing at the same Playwright configuration, so an edge case that only reproduces in one engine still has a defined place to be run. The manifest also lists jsdom for the unit test environment, which is what allows the editor logic to be tested without a real browser.

One gap is worth naming. The browser tests are the only coverage visible in the manifest, and there is no accessibility test tooling listed, no visual regression suite, and no cross browser test for a screen reader. Accessibility here is a design intention and a documentation page, not something the test scripts verify automatically.

## Where Lexxy is the wrong tool

Lexxy is built for one stack, and the edges of that stack are where it stops being a good fit.

It is a Rails editor. Applications on other frameworks have no reason to adopt it, since the Action Text compatibility is the feature that justifies the whole design.

It is an Action Text editor. The compatibility claim covers the canonical HTML format for attachments. If your application stores rich text in another form, or parses it with its own pipeline, that claim does not reach your case.

It is a front end with a specific engine. Lexical is a Meta framework, and the project treats it as a moving dependency, to the point of shipping a script to link a local development version. Teams that need to pin, fork, or audit the editor engine itself should read the dependency setup first.

It is also a young release line, despite recent activity. The version history shows v0.9.33 on 2026-09-22, v1.0.0 on 2026-09-28, and v1.0.1 on 2026-10-09, and the last push was on 2026-10-17. The cadence around the 1.0 boundary was fast, which means a public API and a configuration surface that may still move. On licence terms the project is straightforward: the gem is offered under the MIT License, and the JavaScript package declares the same MIT terms, so there is no copyleft obligation to reason about before adopting it.

## Conclusion

Adopt Lexxy if your Rails app already stores rich text through Action Text and you want a Lexical based editing experience with markdown shortcuts, prompts and attachment previews while keeping stored documents readable. Do not adopt it for a non Rails stack, for a non Action Text rich text pipeline, or for a content workflow that depends on editor specific features the README does not list. Before committing, check the Action Text compatibility path in your own app, since Lexxy only claims the same canonical HTML format for attachments, and confirm the current release, v1.0.1 dated 2026-10-09, matches the version your bundle would lock.

## FAQ

### Does Lexxy work with Action Text without changing stored content?

Yes. The README states that Lexxy works with Action Text, generating the same canonical HTML format it expects for attachments, so the swap affects the editing experience rather than the stored representation.

### What is Lexxy built on?

It is built on top of Lexical, the text editor framework from Meta, and the editing surface ships as the npm package @37signals/lexxy alongside a Ruby gem.

### How do I try Lexxy before installing it?

The README links a sandbox at https://lexxy.dev/sandbox/ where the editor can be tried directly, and the documentation is at https://lexxy.dev/docs/.

### Is Lexxy actively maintained?

The repository is not archived and the last push was on 2026-10-17, with v1.0.1 released on 2026-10-09 and v1.0.0 on 2026-09-28.

### Does Lexxy support mentions and markdown?

Yes. It supports markdown shortcuts and auto-formatting on paste, plus configurable prompts for mentions and other interactive prompts with multiple loading and filtering strategies.

### What licence does Lexxy use?

The gem is available as open source under the terms of the MIT License, and the JavaScript package declares the same MIT licence.

## Sources

- [basecamp/lexxy on GitHub](https://github.com/basecamp/lexxy)
- [License: MIT](https://github.com/basecamp/lexxy/blob/main/LICENSE)
- [Project website](https://lexxy.dev)
- [README](https://github.com/basecamp/lexxy/blob/main/README.md)
- [Releases](https://github.com/basecamp/lexxy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/basecamp-lexxy