These answers describe the Plite package set.
Plite does not know your product schema. It cannot safely turn arbitrary HTML into your nodes without an app-owned policy.
Paste first tries an internal Plite fragment, then registered DataTransfer
formats, and finally plain text. Intercept domCommands.insertData
through plugin commands when the app wants to consume DataTransfer HTML,
files, or custom MIME data. Return a transaction spec when the interceptor owns
the paste, or next() to continue the default import path.
Use Plite DOM, Event Handling, and the Paste HTML example as the starting points.
Desktop browser behavior is claimed only where tests and browser proof cover it.
The main local lanes target current Chromium, Firefox, Safari/WebKit, and mobile viewport rows through Playwright. Raw mobile-device behavior is a separate proof lane and should not be inferred from a desktop browser run.
If a behavior depends on native selection, IME, clipboard, drag/drop, hidden DOM, or huge documents, verify it through browser proof before treating it as supported.
No. This is the Plite package set. It keeps a plain JSON document model, but its canonical change engine, runtime, package names, proof harness, and public API are maintained in the Plate repository.
Read Why This Fork for the maintenance philosophy and boundaries.
@platejs/test?Use @platejs/test for tests and proof harnesses. Do not build product editor features on it.
Apps should build editors with plitejs, plitejs/dom, plitejs/react, and the plugins they need.
Start with Installing Plite. Then read Why This Fork if you need the project boundary, or Migration if you are moving from upstream Slate 0.x.