## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work
> - People write almost every issue, goal, document, and chat message
through the rich markdown editor, which wraps `@mdxeditor/editor` on top
of Lexical
> - #12317 fixed a dependency split that broke that editor everywhere,
and it added `ui/src/lib/lexical-single-copy.test.ts` to keep the
Lexical graph honest
> - Greptile raised a P2 on the last assertion in that test. It compared
the range `@mdxeditor/editor` declares to a literal string, so it
rejected equivalent spellings such as `>=0.48.0 <0.49.0` even when the
resolved version satisfies them
> - A guard that fails on a healthy tree teaches people to delete it,
which would give back the protection #12317 just added
> - #12317 merged before the fix landed, so this pull request carries it
> - This pull request stops the test from reading semver ranges at all,
and asserts the mechanism that can actually break the graph
> - The benefit is a guard that fails only on a real problem, and a
smaller test file than before
## Linked Issues or Issue Description
Refs #12317 — this addresses the Greptile P2 left on that pull request.
No public issue exists, so the problem is described below with the bug
report template.
**What happened?**
`ui/src/lib/lexical-single-copy.test.ts` asserted the declared range
with an exact string comparison:
```ts
const [major, minor] = versionOf("lexical", requireFromUi).split(".");
expect(declared).toBe(`^${major}.${minor}.0`);
```
That accepts one spelling only. If `@mdxeditor/editor` published
`>=0.48.0 <0.49.0`, or `^0.48.2`, or `^0.47.0 || ^0.48.0`, the test
would fail even though the resolved Lexical version satisfies the
declared range. The test would report a dependency split that does not
exist.
**Expected behavior**
The test fails when the Lexical graph is actually split or forced. It
passes on any healthy tree, whatever range syntax the editor happens to
publish.
**Steps to reproduce**
1. Check out `master` at c8a136fb0.
2. Edit `ui/node_modules/@mdxeditor/editor/package.json` and change
`"lexical": "^0.48.0"` to the equivalent `"lexical": ">=0.48.0
<0.49.0"`.
3. Run `npx vitest run ui/src/lib/lexical-single-copy.test.ts`.
4. The range case fails, although 0.48.0 satisfies the range.
**Paperclip version or commit**
`master` at c8a136fb0. The assertion arrived with #12317.
**Relevant logs or output**
```
AssertionError: expected '>=0.48.0 <0.49.0' to be '^0.48.0' // Object.is equality
```
## What Changed
The test no longer reads semver ranges. It asserts the mechanism
instead.
- Replaced the range assertion with a check that no `lexical` or
`@lexical/*` key appears in the root `pnpm.overrides`. The failure
message names the fix.
- Removed the range assertion and the version-line comparison that stood
in for it. Both needed range syntax to mean something specific.
- Documented on the copy check why it now carries the whole guarantee.
Why this is sufficient, and stronger:
- An override is the only thing that can push a resolved version outside
the range a package declares. Remove the override and pnpm honours every
declared range by construction, so `@mdxeditor/editor` gets a Lexical it
supports. No parser needed.
- `@mdxeditor/editor` resolved its own Lexical from its own declared
range. The copy check asserts the app resolved the same version. So an
equal version proves the app sits on a line the editor supports,
transitively.
- It also closes the second half of the original bug. The old override
list could only pin the packages it named, and `@lexical/extension` was
reached transitively and never listed. A guard on "no Lexical override
at all" has no such blind spot, while a guard on "the override pins the
right version" would have.
The file is 65 lines shorter than the first attempt and no longer
carries a hand-rolled semver evaluator.
I considered two alternatives and rejected both. A `semver` dependency
in `ui` would work, but `ui` cannot resolve `semver` today and a new
direct dependency is a heavy way to buy one assertion. A larger
hand-rolled evaluator would have to cover partial versions, wildcards,
hyphen ranges, and spaced comparators before it stopped producing false
failures, which is a semver library with fewer tests.
Nothing outside this test file changes. The Lexical pins from #12317
stay as they are, and `pnpm-lock.yaml` is untouched because no manifest
changes.
## Verification
- `npx vitest run ui/src/lib/lexical-single-copy.test.ts` — 3 passed.
- `pnpm --filter @paperclipai/ui typecheck` — clean.
- Regression still caught. I restored the pre-#12317 pins, which are the
0.49.0 `pnpm.overrides` block and the 0.49.0 pins in `ui/package.json`,
ran `pnpm install`, and re-ran the guard. Two of the three cases failed,
and the new one reports the cause and the fix together:
```
AssertionError: Pin Lexical through ui/package.json instead. An override cannot
cover the packages it does not name, and it hides the range @mdxeditor/editor
declares.: expected [ 'lexical', …(9) ] to deeply equal []
AssertionError: expected '0.48.0' to be '0.49.0'
```
I then restored the current pins and re-ran the guard, which passed 3 of
3.
- `npx vitest run ui/src/lib/mention-deletion.test.ts
ui/src/lib/mention-aware-link-node.test.ts
ui/src/components/MarkdownEditor.test.tsx` — 42 passed, unchanged.
## Risks
- Low risk. The change touches one test file and no application code.
- The guard now forbids a legitimate tool. If someone later has a real
need for a Lexical `pnpm.overrides` entry, this test blocks it. That is
deliberate: an override is what broke the editor, and the block is one
line to remove with a reviewer looking at it. The failure message states
the supported alternative, which is pinning in `ui/package.json`.
- The guard no longer checks the declared range directly. It relies on
pnpm honouring declared ranges when no override is present, which is the
package manager's contract and the same property `pnpm install
--frozen-lockfile` depends on in CI.
- The ordering #12317 set out still holds: a Lexical upgrade must wait
for an `@mdxeditor/editor` release that supports it. Bumping `ui` past
the editor's range now produces two copies, which the copy checks fail
on.
> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.
## Model Used
Claude (Anthropic), Claude Opus, agentic tool use via Claude Code.
- Provider and model: Claude (Anthropic), Claude Opus
- Capability: agentic tool use through Claude Code, with repository
search, file edits, dependency installation, test and build runs
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes (the
reasoning lives in comments in the test file; no document states a
Lexical version or pinning policy)
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work
> - People write almost every issue, goal, document, and chat message
through the rich markdown editor, which wraps `@mdxeditor/editor` on top
of Lexical
> - On `master` that editor renders its raw-source textarea instead. It
shows "Rich editor unavailable for this markdown" on every field, for
all content, including empty content
> - Lexical throws at render time because the project holds two copies
of `LexicalBuilder`. The root `pnpm.overrides` block forced the Lexical
family past the version range the editor supports, and it missed the
packages that are reached transitively
> - Every markdown surface in the product degrades to plain text
editing, so this is a full loss of a core authoring feature and not a
cosmetic problem
> - This pull request removes the Lexical entries from `pnpm.overrides`,
pins the app to Lexical 0.48.0, and adds a test that guards the
resolution graph
> - The benefit is that the rich editor renders again, and a future
override or bump that splits Lexical fails in CI instead of in the
browser
## Linked Issues or Issue Description
No public issue exists. The problem is described below with the bug
report template.
**What happened?**
The rich markdown editor falls back to its raw-source textarea on every
markdown field. The header reads "Rich editor unavailable for this
markdown. Showing raw source instead." The fallback appears for all
content, including empty content. React catches an error during the
first render of the editor.
The cause is dependency resolution. The root `package.json`
`pnpm.overrides` block pinned the Lexical family to `0.49.0`.
`@mdxeditor/editor@4.2.1` declares `lexical: "^0.48.0"`. A caret range
on a `0.x` version pins the minor, so `^0.48.0` means `>=0.48.0
<0.49.0`. The override therefore pushed the editor past its only
supported line. Lexical 0.49.0 also carries breaking `$config()` node
changes.
The override list was also incomplete. `@lexical/extension`,
`@lexical/history`, and `@lexical/internal` are reached transitively and
were never listed. Those packages stayed on 0.48 while the listed
packages moved to 0.49. The graph mixed the two lines, and the built
browser bundle carried two
`Symbol.for("@lexical/extension/LexicalBuilder")` registrations.
Commit 04432f82c (#10728) introduced this. It was a Dependabot bump from
0.46.0 to 0.49.0.
**Expected behavior**
The rich editor renders a live WYSIWYG surface on every markdown field.
The raw-source fallback stays reserved for real markdown parse failures.
**Steps to reproduce**
1. Check out `master` and run `pnpm install`.
2. Start the app and open any issue, goal, or document.
3. Look at any markdown field, for example the issue description.
4. The field shows the fallback banner and a plain textarea. The rich
toolbar is absent.
You can also see the split without the browser:
```
pnpm --filter @paperclipai/ui build
grep -ohE 'Symbol\.for\("@lexical/extension/LexicalBuilder"\)' ui/dist/assets/index-*.js | wc -l
```
On `master` this prints `2`. A correct graph prints `1`.
**Paperclip version or commit**
`master` at 1ba7b2cc7. The regression entered at 04432f82c (#10728).
**Relevant logs or output**
```
LexicalBuilder.fromEditor: The given editor was created with LexicalBuilder
0.48.0+dev.esm but this version is 0.49.0+dev.esm. A project should have
exactly one copy of LexicalBuilder
```
React reports the error in `<LexicalExtensionEditorComposer>`.
`MarkdownEditorRichErrorBoundary` catches it and shows the raw-source
fallback.
## What Changed
- Removed the Lexical entries from `pnpm.overrides` in the root
`package.json`. This drops `lexical`, `@lexical/clipboard`,
`@lexical/link`, `@lexical/list`, `@lexical/markdown`,
`@lexical/plain-text`, `@lexical/react`, `@lexical/rich-text`,
`@lexical/selection`, and `@lexical/utils`. The `rollup`, `react`, and
`react-dom` overrides stay as they are.
- Pinned `lexical` and `@lexical/link` to `0.48.0` in `ui/package.json`.
The app subclasses `LinkNode` for mention-aware links and registers it
into the Lexical instance that MDXEditor owns, so node identity needs
one copy. `@lexical/link@0.48.0` pins `lexical` at `0.48.0` exactly.
- Left `pnpm-lock.yaml` out of this commit on purpose. The `policy` job
blocks manual lockfile edits, regenerates the lockfile from the
manifests, and uploads it for the downstream `pnpm install
--frozen-lockfile` jobs. I did regenerate the lockfile locally to verify
the result. That local lockfile touched only Lexical and MDXEditor
entries and held no Lexical 0.49 reference.
- Added `ui/src/lib/lexical-single-copy.test.ts`. It asserts the app and
the editor resolve the same `lexical` file, that `@lexical/link` and the
transitively reached `@lexical/extension` sit on that version, and that
the version satisfies the range the editor declares.
`ui` is the only workspace package that declares a Lexical dependency,
so nothing else changes.
### Why the overrides can go
#9180 added the Lexical overrides for a good reason. At that time the
app used Lexical 0.46.0 and `@mdxeditor/editor` declared
`lexical@^0.35.0`. The two ranges could not meet, so an override was the
only way to force one copy.
That condition is gone. `@mdxeditor/editor@4.2.1` now declares `lexical:
"^0.48.0"`. When the app also declares `0.48.0`, pnpm resolves one copy
on its own and the override has nothing left to do.
The override is now a liability. It can only pin the packages it lists
by name. `@lexical/extension` did not exist when the list was written,
so the list never covered it, and the list silently stopped covering the
whole family. Natural resolution has no such blind spot, because every
Lexical package carries its own exact pin on the core.
The existing `lexical` alias in `ui/vite.config.ts` and
`ui/vitest.config.ts` stays. It still resolves at 0.48.0. Note that the
alias covers only the `lexical` core, which is why it did not prevent
this bug and why the new test reads the resolution graph with
`createRequire` instead of importing Lexical.
### Related pull requests
- #10728 — the Dependabot bump that introduced the regression.
Superseded by this change.
- #10724 — the companion core bump merged the same day.
- #9180 — added the overrides block that this change removes. See the
explanation above.
- #9179 — an older, still-open 0.46.0 bump. It is stale and this change
does not depend on it.
I found no open pull request that already fixes this problem.
## Verification
All commands ran from the repository root.
- `npx vitest run ui/src/lib/lexical-single-copy.test.ts` — 3 passed.
- Guard proven against the broken tree. I restored the pre-fix
`package.json`, `ui/package.json`, and `pnpm-lock.yaml`, ran `pnpm
install`, and re-ran the guard. It failed 2 of 3: `expected '0.48.0' to
be '0.49.0'` for `@lexical/extension`, and `expected '^0.48.0' to be
'^0.49.0'` for the declared range. I then restored the fix and `pnpm
install` reproduced the committed lockfile byte for byte.
- `pnpm --filter @paperclipai/ui typecheck` — clean. The Lexical API
calls in the app still compile on 0.48.
- `npx vitest run ui/src/lib/mention-deletion.test.ts
ui/src/lib/mention-aware-link-node.test.ts
ui/src/components/MarkdownEditor.test.tsx` — 42 passed.
- `pnpm --filter @paperclipai/ui build`, then the `grep` above — the
bundle now holds 1 `LexicalBuilder` registration. It held 2 before this
change.
- Full `ui` project: `npx vitest run --project '@paperclipai/ui'` — 4426
of 4431 passed. I re-ran the 5 failures in isolation. Four passed, so
they were load-induced 5 second timeouts in
`CompanyEnvironments.test.tsx` and `IssuesList.test.tsx`. The last one,
`OnboardingWizard.test.tsx > renders instead of throwing when the
browser denies storage access`, also fails on clean `master` and is
unrelated to this change.
- Real render probe. I wrote a throwaway test that renders
`MarkdownEditor` against the real `@mdxeditor/editor` with no mock.
Before this change it produced the fallback banner and the
`LexicalBuilder` error. After this change the editor mounts a live
`contenteditable` surface and logs no error. The probe was temporary and
is not part of this diff.
## Risks
- This pins the app's Lexical to the line the editor supports rather
than to the newest release. A future Lexical upgrade must wait for an
`@mdxeditor/editor` release that supports it. I checked published
`@mdxeditor/editor` through 4.2.3 and none supports Lexical 0.49, so
fixing forward is not possible today. The new test enforces that
ordering, so an upgrade attempt fails in CI with a clear reason.
- Dependabot will offer the Lexical 0.49 bump again. The new test will
fail that pull request. That is the intended behavior. A reviewer should
keep the bump closed until MDXEditor moves first.
- 04432f82c was a routine version bump and not a security fix, so this
change reintroduces no known advisory.
- The change is limited to dependency resolution and one new test. It
alters no application code.
> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.
## Model Used
Claude (Anthropic), Claude Opus, agentic tool use via Claude Code.
- Provider and model: Claude (Anthropic), Claude Opus
- Capability: agentic tool use through Claude Code, with repository
search, file edits, dependency installation, test and build runs
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes (no
document in the repository states a Lexical version or pinning policy,
so the reasoning is recorded in the new test's header comment)
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge
Devin Foley