Slate work happens in the Plate repository. Treat issues and PRs as execution handoffs: name the affected package, show the behavior, and include the smallest proof that would let a maintainer or agent continue locally.
On This Page
What Fits
Good Slate contributions improve one of these surfaces:
- editor runtime correctness in
@platejs/slate; - DOM, clipboard, hotkey, or browser bridge behavior in
@platejs/slate-dom; - React editor behavior in
@platejs/slate-react; - history behavior in
@platejs/slate-history; - Yjs adapter behavior in
@platejs/yjs; - layout proof in
@platejs/slate-layout; - browser proof in
@platejs/browser; - docs and examples under
content/docs/slate/**and/examples/slate/*.
Do not add compatibility aliases, wrapper APIs, or old Slate 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:
pnpm installpnpm installRun the smallest relevant lane first. Do not start with the full repo check unless the change truly crosses the whole repo.
pnpm slate:packages:typecheck
pnpm slate:packages:test
pnpm --filter www check:docspnpm slate:packages:typecheck
pnpm slate:packages:test
pnpm --filter www check:docsUse pnpm check:slate:fast for normal Slate confidence:
pnpm check:slate:fastpnpm check:slate:fastUse pnpm check:slate for release or deletion confidence:
pnpm check:slatepnpm check:slateSlate Proof Lanes
| Change | Start with |
|---|---|
| Core runtime, transforms, operations, nodes, locations | pnpm --filter @platejs/slate test |
| React editor behavior | pnpm --filter @platejs/slate-react test |
| History | pnpm --filter @platejs/slate-history test |
| DOM bridge or browser harness | pnpm --filter @platejs/browser test |
| Yjs adapter | pnpm --filter @platejs/yjs test |
| Layout | pnpm --filter @platejs/slate-layout test |
| Docs source | pnpm --filter www check:docs |
| Example browser behavior | pnpm --filter slate test:slate-browser:chromium <file-or-grep> |
| Full browser matrix | pnpm check:slate:browser-matrix |
Browser proof should hit /examples/slate/*, 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.