Contributing

Good Plite contributions improve one of these surfaces:

• editor runtime correctness in @platejs/plite;
• DOM, clipboard, hotkey, or browser bridge behavior in @platejs/plite-dom;
• React editor behavior in @platejs/plite-react;
• history behavior in @platejs/plite-history;
• Yjs adapter behavior in @platejs/yjs;
• layout proof in @platejs/plite-layout;
• browser proof in @platejs/browser;
• docs and examples under content/docs/plite/** and /examples/plite/*.

Do not add compatibility aliases, wrapper APIs, or old Plite helper shims. If the current API is wrong, propose the better current API and prove it.

Bug Reports

Editor bugs need more than a screenshot.

Include:

• the exact docs page, example route, package, or API involved;
• expected behavior;
• actual behavior;
• browser, OS, and input method;
• a minimal value or code path;
• a short recording when the bug is visual;
• focused reproduction steps;
• whether the bug affects model state, rendered DOM, native selection, focus, paste, undo/redo, or follow-up typing.

For selection, paste, IME, void, hidden DOM, or huge-document behavior, include browser-visible evidence. Model-only tests are useful, but they do not prove contenteditable behavior.

Pull Requests

Keep PRs narrow and takeover-ready.

Every behavior PR should include:

• the package or docs owner;
• the bug or design reason;
• the smallest source change;
• a focused test, browser proof, or explicit reason no automated proof fits;
• the exact command that proves the change;
• docs updates when public behavior or API changes.

If a PR changes package exports, run pnpm brl. If it changes published package behavior, add the right changeset unless a maintainer explicitly says the release lane does not need one.

Local Setup

Install dependencies from the repository root:

Run the smallest relevant lane first. Do not start with the full repo check unless the change truly crosses the whole repo.

Use pnpm check:plite:fast for normal Plite confidence:

Use pnpm check:plite for release or deletion confidence:

Plite Proof Lanes

Browser proof should hit /examples/plite/*, not docs pages. Docs pages prove reading and navigation. Example routes prove editor behavior.

Docs Changes

Docs should describe the current API, not migration history.

Use:

• exact package names;
• exact import specifiers;
• runnable examples;
• links to real leaf docs;
• source-backed claims;
• short openings;
• scan-friendly headings and tables when a page is large.

Do not write placeholder prose, fake APIs, stale upstream URLs, or broad claims that the proof lane does not own.

Release Authority

Public release, package promotion, and npm publishing decisions belong to maintainers. A contribution can prepare proof and docs, but it should not claim release readiness unless the release lane has run.