@jielga/tmdatagrid 0.3.0 → 1.0.0-beta.0

package/README.md

@@ -95,7 +95,9 @@ demo site:
 | [Components](src/docs/components.md)           | Props for every component        |
 | [Columns](src/docs/columns.md)                 | Definitions, sizing and filters  |
 | [Features](src/docs/features.md)               | Enabling and disabling behaviour |
+| [Editing](src/docs/editing.md)                 | Modes, editors and validation    |
 | [Server-side](src/docs/server-side.md)         | Manual pagination and filtering  |
+| [Testing](src/docs/testing.md)                 | Part hooks, roles and Playwright |
 
 ## Development
 
@@ -109,9 +111,26 @@ is the demo site that documents it.
 | `core/`             | Headless logic: filtering, ordering, persistence, capabilities |
 | `components/`       | The React chrome and its co-located CSS modules               |
 
+### Examples
+
+The demo site's examples live in [`src/examples/`](src/examples):
+
+| Path              | Contents                                                       |
+| ----------------- | -------------------------------------------------------------- |
+| `examplePages.ts` | The tree — categories, topics, and the prose for every demo     |
+| `demos/`          | One file per demo: one idea, no headings, no explanation        |
+| `data/`           | Shared datasets, and the column set for demos about other things |
+| `playground/`     | The kitchen sink, every feature at once behind switches          |
+
+Adding a demo is adding a file under `demos/` and naming it from a topic in
+`examplePages.ts` — the registry pairs each module with its own source through
+`import.meta.glob`, so the code on screen cannot drift from the code running.
+[`demos.test.tsx`](src/examples/demos.test.tsx) mounts every registered demo,
+so a demo that stops working fails the suite whether or not it still compiles.
+
 ```sh
 npm install
-npm run dev    # demo site with the grid example and docs
+npm run dev    # demo site: examples, playground and docs
 npm run lint   # oxlint
 npm run test   # vitest, once
 npm run test:watch
@@ -119,6 +138,10 @@ npm run test:watch
 
 ## Testing
 
+For testing an application that *uses* the grid — the test ids, roles and ARIA
+attributes it publishes, and how to drive it from Playwright — see
+[Testing](src/docs/testing.md). What follows is about this repo's own suite.
+
 Vitest with React Testing Library, in jsdom. Tests sit next to the code they
 cover as `*.test.ts(x)` and are excluded from both the package and the
 declaration build; shared fixtures live in [`src/test/`](src/test) so they stay
@@ -184,7 +207,7 @@ The package build runs from `prepublishOnly` rather than as a workflow step, so
 `metadata.library_version` in every `skills/*/SKILL.md` to the new version.
 
 Intent reports a skill as stale when its `library_version` trails the package
-version, so without that step every release would leave all five skills stale.
+version, so without that step every release would leave every skill stale.
 Because it runs inside the version command, the bump and the skill sync land in
 the same PR and are reviewed together.