` plain `SVGElement`s. Reading one of them off `SVGElement.prototype` - like when spying on the mocks - therefore needs the exported `MockedSVGElement` type. For example:\n\n```ts\nimport type { MockedSVGElement } from '@joint/mock-svg';\n\njest.spyOn(SVGElement.prototype as MockedSVGElement, 'getBBox')\n .mockReturnValue({ x: 0, y: 0, width: 100, height: 50 } as DOMRect);\n```\n\n## License\n\nThe *@joint/mock-svg* library is licensed under the [MIT License](https://github.com/clientIO/joint/blob/master/packages/joint-mock-svg/LICENSE).\n\nCopyright © 2013-2026 client IO\n","packages/joint-react/CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with\ncode in this repository.\n\n## Project Overview\n\n`@joint/react` is the React bindings library for JointJS. It provides React\ncomponents and hooks for building diagramming applications with JointJS,\nrendering diagram elements as React components via SVG foreignObject portals.\n\n**Stack:** TypeScript 5.9, React 19 (peer: >=18), Rollup + esbuild (build), Vite\n(storybook/dev), Jest 30 + @testing-library/react (testing), ESLint 9 flat\nconfig, Storybook 10\n\n## Common Commands\n\n```bash\n# Build (Rollup + esbuild → dist/cjs, dist/esm, dist/types)\nyarn build\n\n# Run all checks (typecheck + knip + jest, once against React 19 and once\n# against React 18)\nyarn test\n\n# Run individual checks\nyarn typecheck # tsc --noEmit\nyarn lint # ESLint\nyarn lint-fix # ESLint with auto-fix\nyarn jest # Jest tests only\n\n# Run a single test file\nyarn jest --testPathPatterns=\"use-elements\"\n\n# Run tests in watch mode\nyarn jest --watch\n\n# Storybook (dev server on :6006)\nyarn storybook\n\n# Build storybook\nyarn build-storybook\n```\n\n## Changesets\n\nReleasable changes need a changeset - the format is defined in the **Changeset\nformat** section of the repository's `CONTRIBUTING.md`. Two things are specific\nto this package:\n\n- The changelog scope is the exported component or hook rather than a JointJS\n namespace - components as JSX tags, hooks by name:\n\n ```markdown\n - fix the visual grid to redraw reactively when `drawGrid` changes\n useCells - fix ghost cells reported after `resetCells()`\n ```\n\n- `@joint/react` is versioned independently. It is not part of the\n `@joint/core` linked group, and because it depends on core via `workspace:^`,\n a `@joint/core` minor release does not drag it along - only a major does.\n\n# Clean Code & Style Guidelines\n\n## General\n\n- Prefer clear, explicit code over clever one-liners. Maintainability > brevity.\n- When editing existing code, preserve the existing style unless I explicitly\n ask for a refactor.\n- Leave code cleaner than you found it. Continuously refactor small things\n instead of accumulating technical debt.\n\n## Constants Over Magic Numbers\n\n- Replace hard-coded values with named constants.\n- Use descriptive constant names that explain the value's purpose.\n- Keep constants at the top of the file\n\n## Meaningful Names\n\n- Variables, functions, and classes should reveal their purpose.\n- Names should explain **why** something exists and **how** it is used.\n- Avoid abbreviations unless they are truly universal (e.g. `id`, `URL`,\n `HTML`).\n- Boolean names must be self-descriptive and read like conditions:\n - Use prefixes: `is`, `has`, `should`, `can`, `must`, `needs` (e.g. `isOpen`,\n `hasError`, `shouldRetry`).\n - Avoid generic names like `flag`, `ok`, `state`, `enabled` without context.\n- Function names should describe behavior, not implementation details.\n\n## File Naming (TypeScript / JavaScript)\n\n- All `.ts`, `.tsx`, `.js`, `.jsx` files must use **kebab-case**:\n - Examples: `user-profile.ts`, `something-table.tsx`\n- React component files:\n - File name: kebab-case (e.g. `user-profile-card.tsx`).\n - Component name inside: `PascalCase` (e.g. `UserProfileCard`).\n\n## Smart Comments\n\n- Do **not** comment on what the code does if the code can be made\n self-explanatory instead.\n- Prefer to improve the code so it reads clearly without comments.\n- Use comments to explain:\n - Why something is done in a non-obvious way.\n - Important constraints, assumptions, or business rules.\n - Non-obvious side effects.\n- Document APIs, complex algorithms, and tricky edge cases.\n\n## Single Responsibility\n\n- Each function should do exactly one thing.\n- Functions should be small and focused.\n- If a function needs a long comment to explain what it does, consider\n splitting it into smaller functions.\n- JSDoc is mandatory for all exported functions.\n\n## DRY (Don't Repeat Yourself)\n\n- Extract repeated code into reusable functions or utilities.\n- Share common logic through proper abstractions.\n- Maintain single sources of truth for configuration, constants, and shared\n logic.\n\n## Clean Structure\n\n- Keep related code together.\n- Organize code in a logical hierarchy (modules, domains, features).\n- Use consistent file and folder naming conventions.\n- Avoid \"god\" files that own too many responsibilities.\n\n## Encapsulation\n\n- Hide implementation details behind clear interfaces.\n- Expose only what is needed from a module.\n- Move nested conditionals or complex logic into well-named helper functions.\n\n## TypeScript\n\n- Never use `any` in new code:\n - Prefer proper types, generics, unions, or `unknown` + narrowing.\n - If `any` is unavoidable at a boundary (e.g. 3rd-party library), isolate it\n and add a clear `TODO` explaining why.\n- Write `strict`-friendly code:\n - No implicit `any`.\n - Avoid sloppy or unnecessary `as` casts.\n - Avoid `as any` and non-null assertions (`!`) unless absolutely necessary;\n justify them with a short comment.\n- Use `interface`/`type` aliases for data structures instead of loose objects.\n- Keep function signatures explicit and well-typed, especially for exported\n functions and public APIs.\n- Prefer readonly/immutable data where reasonable (e.g. `readonly` props, avoid\n mutating function arguments).\n\n## Performance Mindset\n\n- Avoid unnecessary allocations and copies:\n - No pointless spreading (`{ ...obj }`) or `JSON.parse(JSON.stringify(...))`\n in hot paths.\n- Avoid creating new functions/objects inside tight loops or very frequently\n rendered components unless memoized.\n- Use `useMemo` / `useCallback` **only** when they prevent real, recurring work\n or re-renders, not everywhere by default.\n- Be careful not to introduce extra re-renders by changing prop shapes\n unnecessarily.\n- Prefer algorithmic improvements and proper data structures over\n micro-optimizations when performance is a concern.\n\n## Code Quality Maintenance\n\n- Refactor continuously in small, safe steps.\n- Fix technical debt early when you touch a piece of code.\n- Prefer explicit, predictable behavior over clever tricks.\n- Keep the codebase internally consistent.\n\n## Testing & Safety\n\n- For non-trivial logic changes, prefer adding or updating tests.\n- Write tests before fixing bugs when possible (regression tests).\n- Keep tests readable, deterministic, and maintainable.\n- Test edge cases, error conditions, and boundary values.\n- Avoid relying on implementation details; test behavior and contracts.\n- Performance is must have, so test it.\n","packages/joint-react/README.md":"\n ![\"JointJS\"](\"https://cdn.prod.website-files.com/63061d4ee85b5a18644f221c/633045c1d726c7116dcbe582_JJS_logo.svg\")
\n
\n\nJointJS for React
\n\n\n Production-scale diagramming for React.
\n A first-class React integration for JointJS — real components and hooks for building complex diagramming apps, with full control over the data model, rendering, and interactions, using the React patterns you already know.\n
\n\n\n ![\"npm\"](\"https://img.shields.io/npm/v/@joint/react?style=flat-square&color=0EA5E9\")
\n ![\"types\"](\"https://img.shields.io/npm/types/@joint/react?style=flat-square&color=3178C6\")
\n ![\"downloads\"](\"https://img.shields.io/npm/dm/@joint/react?style=flat-square&color=F59E0B\")
\n ![\"license\"](\"https://img.shields.io/npm/l/@joint/react?style=flat-square&color=10B981\")
\n
\n\n\n 🚀 Quick start ·\n 🧩 Live Example ·\n 📖 Learn more\n
\n\n[](https://github.com/user-attachments/assets/fc6de738-3fad-48f7-99aa-ba8c3729d9b1)\n\n---\n\nBuilt on the proven JointJS core, you get a mature diagramming UI library and an idiomatic React layer in one. Like JointJS, it's open source.\n\n## Why JointJS for React\n\n- **A real data model.** A serializable graph you can query, transform, and persist — the backbone for complex, stateful diagram applications, not just visual nodes.\n- **Full control.** Complete control over how diagrams render and behave — shapes, ports, links, routing, and custom interactions.\n- **Production-grade UX.** The interaction details end users expect come built in: connection snapping, link routing that avoids obstacles, element and link tools, highlighters for hover and selection states. Good UX is designed into every feature, not left for you to assemble.\n- **Performance at scale.** Smooth interaction on large graphs with thousands of nodes.\n- **Idiomatic React.** Real components and hooks that fit naturally into your existing React app and tooling.\n\n## Installation\n\n```bash\nnpm install @joint/react # or pnpm add / yarn add / bun add\n```\n\nPeer dependency: **React 18 or 19**.\n\n## Quick start\n\n```tsx\nimport { GraphProvider, Paper, HTMLBox, type CellRecord } from '@joint/react';\n\ninterface NodeData {\n label: string;\n}\n\nconst initialCells: ReadonlyArray> = [\n { id: '1', type: 'element', position: { x: 40, y: 40 }, data: { label: 'Hello' } },\n { id: '2', type: 'element', position: { x: 280, y: 180 }, data: { label: 'World' } },\n { id: '1 → 2', type: 'link', source: { id: '1' }, target: { id: '2' } },\n];\n\nfunction renderElement(data: NodeData) {\n return {data.label};\n}\n\nexport default function Diagram() {\n return (\n \n \n \n );\n}\n```\n\n`GraphProvider` holds the graph state, `Paper` renders it, and `renderElement` turns each node's data into a React component. See [Learn more](#learn-more) for the full getting-started guide.\n\n## When is JointJS for React the right choice?\n\nJointJS for React is built for production-scale diagramming — applications where the diagram is a core part of the product and has to handle real complexity: a rich data model, large graphs, domain-specific shapes, and deep control over interactions and rendering.\n\nProduction-scale is not only about node count. Most workflow tools top out at tens of nodes, yet their users still expect a polished editing experience: precise connections, clear feedback on hover and selection, links that route cleanly around obstacles. JointJS for React treats that end-user UX as part of the library, so you ship it instead of building it.\n\nIt's designed to be the layer you build on as your requirements grow, from the first prototype through to a mature, scaling application.\n\n## Use cases\n\nJointJS for React is used to build production diagramming applications across many domains:\n\n| Domain | Examples |\n|---|---|\n| Workflow & process | Flowchart editors, process automation, activity and sequence diagrams |\n| AI workflow builders | Node-based AI pipeline and agent builders, marketing automation studios |\n| BPMN | Business process modelers, swimlanes, Visio BPMN import/export |\n| Data modeling | ER diagrams, database schema design, data lineage and mapping |\n| UML & software modeling | Class, sequence, statechart and use-case diagrams |\n| Industrial / SCADA & HMI | SCADA interfaces, HMI control panels, P&ID and process diagrams |\n| Energy networks | Power grid and substation diagrams, telecom and fiber (DWDM) network design |\n| Electronic design | Circuit and logic design, wiring and cable harness diagrams, schematic capture |\n| Org charts | Org charts, reporting hierarchies, team and headcount planning |\n| Timelines | Project and milestone timelines, Gantt and PERT charts |\n\nExplore the [demos](https://www.jointjs.com/demos) to see them in action.\n\n## Learn more\n\n- 📖 [Learn JointJS for React](https://docs.jointjs.com/react)\n- 🧾 [API reference](https://docs.jointjs.com/api-react)\n- 🖼️ [Examples](https://www.jointjs.com/demos)\n- 📚 [Storybook](https://react.jointjs.com/learn/)\n- 🤖 [MCP server](#using-jointjs-for-react-with-ai-coding-agents)\n- 💬 [Ask a question or share feedback](https://github.com/clientIO/joint/discussions)\n\n## Using JointJS for React with AI coding agents\n\nJointJS is built to work well with AI-assisted development.\n\n**MCP server** — connect your AI coding agent (Claude Code, Cursor, and other MCP-compatible tools) to the JointJS Model Context Protocol server so it can search the official docs and demos while you build:\n\n```\nhttps://mcp.jointjs.com/mcp\n```\n\nIt exposes `search_docs` and `search_demos`, so your agent writes correct JointJS for React code against the real API instead of guessing.\n\n## Commercial version\n\nThe open-source library covers core diagramming. **JointJS+ for React** is the commercial extension that takes the end-user experience further with production-ready plugins — stencils, toolbars, snaplines, keyboard shortcuts, undo/redo, advanced layouts, import/export, and more — plus professional demo apps (including source code) and direct support from the team that builds the library. [Start a free 30-day trial.](https://www.jointjs.com/free-trial)\n\n## License\n\nJointJS for React is licensed under the [Mozilla Public License 2.0](https://github.com/clientIO/joint/blob/master/LICENSE).\n\nCopyright © 2013-2026 client IO\n","packages/joint-router-avoid/README.md":"# JointJS Avoid Router\n\nA module that routes *[JointJS](https://www.jointjs.com)* links using [libavoid](https://github.com/mjwybrow/libavoid), a C++ library for automatic, obstacle-avoiding orthogonal connector routing, compiled to WebAssembly via [libavoid-js](https://github.com/Aksem/libavoid-js).\n\nThis library fully depends on [JointJS](https://github.com/clientio/joint) (*>=4.0*), so please read its `README.md` before using this library.\n\nlibavoid maintains a single incremental router shared by the whole graph: it tracks every element as an obstacle and every link as a connector, and reroutes affected connectors whenever obstacles move. This package wraps that behavior in a `RouterService` that listens to a `dia.Graph` and, whenever libavoid computes a new route for a link, applies it directly to that link's `vertices` and source/target anchors - there is no `router: { name: ... }` attribute to set on links; once a link is connected to two elements on a routed graph, it is routed automatically. See [`examples/avoid-router-ts`](https://github.com/clientIO/joint/tree/master/examples/avoid-router-ts) for a full demo.\n\n## 🚀 Quick Start\n\n### Installation\n\n```bash\nnpm install @joint/router-avoid\n```\n\n### Basic Usage\n\n```ts\nimport { dia, shapes } from '@joint/core';\nimport { initAvoidRouter } from '@joint/router-avoid';\n\nconst graph = new dia.Graph({}, { cellNamespace: shapes });\nconst paper = new dia.Paper({\n model: graph,\n cellViewNamespace: shapes,\n el: document.getElementById('paper'),\n});\n\n// Loads the libavoid-js WebAssembly module (if not already loaded), then\n// registers every element/link currently in the graph as an avoid\n// obstacle/connector and keeps them in sync with future graph changes.\nconst routerService = await initAvoidRouter(graph, {\n shapeBufferDistance: 20,\n idealNudgingDistance: 10,\n});\n\n// ... add elements and links to the graph - links connected to two\n// elements are picked up and routed automatically, no `router`\n// attribute needed:\n// new shapes.standard.Link({ source: { id: a.id }, target: { id: b.id } });\n\n// Stop routing this graph and release the underlying resources\n// (e.g. terminate a Worker thread) when they're no longer needed.\n// routerService.destroy();\n```\n\n`initAvoidRouter()` resolves once the module is loaded and the current graph content has been registered with libavoid; the routes themselves are still computed asynchronously and applied as they come in - listen for the `link:routed` event to know when a specific link's route has settled (see below).\n\nLoaded as a script tag rather than via ESM, the same functions are available as `joint.routers.avoid.initAvoidRouter` / `joint.routers.avoid.loadAvoidRouter` on the UMD build.\n\n## 📖 API Reference\n\n### `loadAvoidRouter(filePath?): Promise`\n\nLoads the `libavoid-js` WebAssembly module. `initAvoidRouter()` calls this automatically if the module isn't loaded yet, so calling it directly is only needed to preload the module ahead of time. Accepts an optional path to the `libavoid.wasm` file if it is not served from its default location. Safe to call multiple times - later calls resolve once the first load completes.\n\n### `initAvoidRouter(graph, options?): Promise`\n\nLoads the module (via `loadAvoidRouter()`, if needed) and creates a `RouterService` for `graph`. The returned service is not started - call `start()` to keep the graph continuously routed, or `routeAll()`/`routeSubgraph()` for a one-shot routing pass.\n\n- `graph`: `dia.Graph` - the graph to route.\n- `options?`: `InitAvoidOptions`\n\n```ts\ninterface InitAvoidOptions {\n shapeBufferDistance?: number; // Default: 10 - spacing added around shapes when computing obstacles, and used as the fallback route's margin around elements\n idealNudgingDistance?: number; // Default: 5 - spacing used to nudge apart overlapping connector segments\n worker?: boolean | WorkerOptions; // Default: false - run libavoid inside a Web Worker instead of the main thread; pass an object to configure the Worker\n libavoidFilePath?: string; // Forwarded to loadAvoidRouter()\n trackLink?: (params: { link: dia.Link }) => boolean; // Which links to route; return false to exclude one. Default: all\n trackElement?: (params: { element: dia.Element }) => boolean; // Which elements to track as avoid obstacles; return false to exclude one. Default: all\n // First refusal on a link avoid can't route because one of its ends\n // isn't connected to a cell ('unconnected'), is connected to another\n // link ('unsupported'), or is connected to an element excluded via\n // `trackElement` ('untracked'). Return true to take over routing that\n // link yourself; otherwise the built-in `rightAngle`-based fallback\n // route is applied.\n interceptUnroutableLink?: (params: { link: dia.Link, reason: 'unconnected' | 'untracked' | 'unsupported' }) => boolean;\n // Override how computed route attributes are applied to a link, e.g. to\n // route the update through a command manager. Default: link.set()\n setRouteAttributes?: (params: { link, attributes, origin, routing, unroutableReason }) => void;\n changeFlag?: string; // Default: 'avoidRouter' - name of the opt flag marking this router's own link.set() calls\n}\n\ninterface WorkerOptions {\n debounceTime?: number; // Default: 100 - ms the Worker waits after the last received change before recomputing routes in a single batch; 0 applies every change immediately\n}\n```\n\n### `RouterService` (returned by `initAvoidRouter()`)\n\nThe object responsible for keeping libavoid's internal obstacle/connector graph in sync with the `dia.Graph`, applying computed routes to links, and emitting routing events. It mixes in JointJS's `mvc.Events` (`on`/`off`/`trigger`).\n\n- `start()` / `stop()` - start/stop listening to graph changes (added/removed cells, moved/resized elements, reconnected links). `start()` also syncs every cell the graph already holds.\n- `isStarted` - whether the service is currently listening to its graph.\n- `routeAll()` - one-shot: routes every cell currently in the graph, resolving once all routes are applied. No graph listener is attached. Throws while started. Resolves with a `RoutingResult` - `{ status: 'done' }`, or `{ status: 'cancelled' }` if the pass was interrupted by `destroy()`. Overlapping calls are queued and run one after another.\n- `routeSubgraph(cells)` - one-shot: routes only `cells`, independently of the rest of the graph (cells outside the array are neither routed nor obstacles). Throws while started. Resolves with the same `RoutingResult` as `routeAll()`.\n- `changeFlag` - the `opt` flag name marking this router's own `link.set()` calls, for filtering them out of your own `change` listeners.\n- `destroy()` - stops routing the graph, cancels open routing cycles, and releases the resources held by the service and its provider (e.g. terminates a Worker thread). Do not use the instance afterwards.\n\n**Events:**\n\n- `link:routing` `(link)` - emitted when a link's route is (re-)computing.\n- `link:routed` `(link, { origin, reason })` - emitted once a link's route has been applied. `origin` is `'avoid'` or `'fallback'`; `reason` is set when the fallback route was applied because the link was unroutable.\n- `link:routing:cancelled` `(link)` - emitted when a link with an open `link:routing` cycle becomes unroutable (e.g. disconnected) before libavoid produced a route for it.\n- `idle` `()` - emitted when there are no more open routing cycles.\n\n## ⚠️ Caveats & Known Limitations\n\n- **Asynchronous setup** - `initAvoidRouter()` loads the WebAssembly module and performs the initial graph sync asynchronously; it must be awaited before the graph is considered routed.\n- **Bundler configuration** - `libavoid-js` ships its logic and the `libavoid.wasm` binary as separate files, and `worker: true` additionally loads this package's own worker script as a module. Consuming applications are responsible for ensuring both are served alongside the rest of the bundle (e.g. via a copy plugin for your bundler of choice).\n- **Fallback routing** - libavoid does not expose a way to check whether a computed route is valid, so a heuristic is used. When the route is deemed invalid, or when a link isn't connected to elements on both ends, the built-in `rightAngle`-based fallback route is applied instead (unless `interceptUnroutableLink` takes over).\n- **One `RouterService` per graph** - constructing more than one `RouterService` for the same `dia.Graph` results in both instances applying routes to the same links; call `destroy()` on a previous instance before creating a new one for the same graph.\n- **Custom vertices (checkpoints)** are not currently supported.\n\n## 📄 License\n\nThe code in this package is licensed under the [Mozilla Public License 2.0](https://www.mozilla.org/en-US/MPL/2.0/), same as the rest of JointJS.\n\nIt depends on [`libavoid-js`](https://www.npmjs.com/package/libavoid-js), a WebAssembly build of [libavoid](https://github.com/mjwybrow/adaptagrams), which is licensed under the **GNU LGPL 2.1 or later** - applications shipping this package also ship the `libavoid.wasm` binary under that license. Keep the binary a separately served file (as described under bundler configuration above); don't configure your bundler to inline it into your application bundle.\n\nCopyright © 2013-2026 client IO\n\nThis package depends on [`libavoid-js`](https://github.com/Aksem/libavoid-js), which is licensed under the [LGPL-2.1-or-later license](https://github.com/Aksem/libavoid-js?tab=LGPL-2.1-1-ov-file#readme).\n","packages/joint-shapes-general-tools/README.md":"# JointJS General Shapes Tools\n\nA collection of ECMAScript / TypeScript tools for use with general *[JointJS](https://www.jointjs.com/)* shapes.\n\nThis library fully depends on [JointJS](https://github.com/clientio/joint) (*>=3.5*), so please read its `README.md` before using this library.\n\n## License\n\n[Mozilla Public License 2.0](https://www.mozilla.org/en-US/MPL/2.0/)\n\nCopyright © 2013-2026 client IO\n","packages/joint-shapes-general/README.md":"# JointJS General Shapes\n\nA collection of general ECMAScript / TypeScript shapes for *[JointJS](https://www.jointjs.com/)*.\n\nThis library fully depends on [JointJS](https://github.com/clientio/joint) (*>=3.5*), so please read its `README.md` before using this library.\n\n## License\n\n[Mozilla Public License 2.0](https://www.mozilla.org/en-US/MPL/2.0/)\n\nCopyright © 2013-2026 client IO\n","packages/joint-vitest-plugin-mock-svg/README.md":"# JointJS Mock SVG plugin for Vitest\n\nA Vitest plugin to mock SVG methods not implemented in JSDOM used by *[JointJS](https://www.jointjs.com/)*.\n\n## Usage\n\nImport the plugin in your `vitest.config.js`:\n\n```js\nimport { defineConfig } from 'vitest/config';\nimport mockSVG from '@joint/vitest-plugin-mock-svg'\n\nexport default defineConfig({\n plugins: [mockSVG()],\n})\n```\n\nThe mocks themselves come from [`@joint/mock-svg`](https://github.com/clientIO/joint/tree/master/packages/joint-mock-svg) as plain functions. If your test needs to assert on one of them, or change what the mock returns, use `vi.spyOn()`.\n\n### Changing what a mock returns\n\nThe default `getBBox()` returns an all-zero rect, which leaves `checkVisibility()` false and `util.breakText()` with nothing to measure. If your test needs one, give the mock a size object as a return value:\n\n```js\nvi.spyOn(SVGElement.prototype, 'getBBox')\n .mockReturnValue({ x: 0, y: 0, width: 100, height: 20 });\n```\n\n`mockRestore()`, `vi.restoreAllMocks()` and `restoreMocks: true` all put the mock back afterwards, so an override stays local to its test and the suite needs no `beforeEach` to reinstall anything.\n\nThe same spy also records calls. This lets you assert whether JointJS measured anything at all:\n\n```js\nconst getBBox = vi.spyOn(SVGElement.prototype, 'getBBox');\nrender();\nexpect(getBBox).toHaveBeenCalled();\n```\n\n`vi.spyOn` reaches nested members, as well - for example `vi.spyOn(SVGElement.prototype.transform.baseVal, 'appendItem')`.\n\nTo swap a mock implementation permanently, reassign it:\n\n```js\nSVGElement.prototype.getComputedTextLength = () => 42;\n```\n\nRestore the previous value yourself if the change should not outlive the file.\n\n### Driving `ResizeObserver`\n\nThe mocked observer accepts a callback and never calls it. To deliver entries, or to assert on `observe`, provide your own:\n\n```js\nglobalThis.ResizeObserver = class {\n observe = vi.fn();\n unobserve = vi.fn();\n disconnect = vi.fn();\n constructor(callback) { this.callback = callback; }\n resize(entries) { this.callback(entries, this); }\n};\n```\n\n## TypeScript\n\n`getBBox()`, `getScreenCTM()`, `getComputedTextLength()` and `transform` are mocked on `SVGElement`, one level wider than where DOM types (`lib.DOM`) declare them, because JSDOM makes ``, `` and `` plain `SVGElement`s. Reading one of them off `SVGElement.prototype` - as every example above does - therefore needs the re-exported `MockedSVGElement` type. For example:\n\n```ts\nimport type { MockedSVGElement } from '@joint/vitest-plugin-mock-svg';\n\nvi.spyOn(SVGElement.prototype as MockedSVGElement, 'getBBox')\n .mockReturnValue({ x: 0, y: 0, width: 100, height: 20 } as DOMRect);\n```\n\n## License\n\nThe *@joint/vitest-plugin-mock-svg* library is licensed under the [MIT License](https://github.com/clientIO/joint/blob/master/packages/joint-vitest-plugin-mock-svg/LICENSE).\n\nCopyright © 2013-2026 client IO\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with\ncode in this repository.\n\n## Project Overview\n\nJointJS is a JavaScript/TypeScript diagramming library for building visual and\nno-code/low-code applications. It's a Yarn workspace monorepo with multiple\npackages.\n\n**Stack:** Node 22.14.0, Yarn 4.18.0, TypeScript 5.8 (5.9 in `joint-react`),\nGrunt (build), QUnit/Karma/Mocha/Jest (testing)\n\n## Common Commands\n\n```bash\n# Install dependencies\nyarn install\n\n# Build distribution files (runs Grunt)\nyarn dist\n\n# Run all tests (QUnit + Jest + TypeScript checks)\nyarn test\n\n# Run specific test types\nyarn test-server # Server-side tests (Node.js)\nyarn test-client # Client-side tests (Browser with Karma)\nyarn test-ts # TypeScript type definition tests\n\n# Linting\nyarn lint # Check all packages\nyarn lint-fix # Auto-fix errors\n\n# Build bundles\nyarn build\nyarn build-bundles\n```\n\n### Running Single Tests\n\nFor joint-react Jest tests:\n```bash\ncd packages/joint-react\nyarn jest --testPathPatterns=\"ComponentName\"\n```\n\n## Architecture\n\n### Monorepo Packages (`/packages`)\n\n- **@joint/core** - Main diagramming library (MVC architecture, SVG rendering)\n- **@joint/react** - React bindings and hooks (Rollup + esbuild, Storybook)\n- **@joint/layout-directed-graph** - Graph layout algorithms\n- **@joint/layout-msagl** - Microsoft MSAGL layout integration\n- **@joint/shapes-general** - General-purpose diagram shapes\n- **@joint/eslint-config** - Shared ESLint configuration\n\n### Core Library Structure (`/packages/joint-core/src`)\n\nThe library follows an MVC pattern:\n\n- **`mvc/`** - Base MVC components: Model, View, Collection, Events, Dom\n- **`dia/`** - Diagramming API built on MVC:\n - `Graph.mjs` - Graph data structure and cell management\n - `Paper.mjs` - SVG canvas and rendering engine\n - `Element.mjs` / `ElementView.mjs` - Diagram nodes\n - `Link.mjs` / `LinkView.mjs` - Connections between elements\n- **`g/`** - Geometry library (points, lines, curves, polygons, matrices)\n- **`V/`** - Vectorizer for SVG manipulation\n- **`connectors/`** - Link path strategies (line, curve, bezier, jumpover)\n- **`routers/`** - Link routing algorithms (manhattan, orthogonal, metro)\n- **`anchors/`** - Connection point anchors on elements\n- **`highlighters/`** - Visual highlighting mechanisms\n- **`linkTools/`**, **`elementTools/`** - Interactive manipulation tools\n- **`shapes/`** - Built-in shapes (standard)\n- **`layout/`** - Built-in layouts (port, port label)\n- **`alg/`** - Graph algorithms (DFS, BFS, shortest path)\n\n### Main Export (`/packages/joint-core/src/core.mjs`)\n\n```javascript\nexport { anchors, linkAnchors, config, connectionPoints, connectionStrategies,\n connectors, dia, env, highlighters, layout, mvc, routers, setTheme,\n util, version, linkTools, elementTools, V, Vectorizer, g };\n```\n\n## Test Organization\n\n- **`/packages/joint-core/test/jointjs/`** - QUnit tests for core functionality\n- **`/packages/joint-core/test/jointjs-nodejs/`** - Mocha tests run by\n `test-server`\n- **`/packages/joint-core/test/geometry/`** - Geometry library tests\n- **`/packages/joint-core/test/vectorizer/`** - SVG vectorizer tests\n- **`/packages/joint-core/test/ts/`**, **`test/ts-exports/`** - TypeScript\n definition validation\n- **`/packages/joint-react/src/`** - Jest tests with @testing-library/react,\n colocated in `__tests__` folders\n\n## Changesets\n\nReleasable changes need a changeset in `/.changeset`. Before writing one, read\nthe **Changeset format** section of `CONTRIBUTING.md` - it defines the required\nfrontmatter, the `scope - description` changelog style (`dia.Paper`, `anchors`,\n``, ...), and the backtick/`()` conventions - and follow it exactly.\n\n## Key Patterns\n\n- **Change tracking:** Models emit `change:*` events; `changeId` event triggers\n only when ID actually changes\n- **Workspace commands:** Use `yarn workspaces foreach --all -tvv run `\n for cross-package operations\n- **TypeScript:** Strict mode enabled; the settings are per package, not\n repo-wide. `tsconfig.common.json` adds `noUnusedLocals`,\n `noUnusedParameters` and `noImplicitReturns`, and is used by `joint-cli`,\n `joint-decorators` and the `shapes-general` packages - `joint-core` and\n `joint-react` each have their own\n- **ESLint:** Uses flat config format (v9) via `@joint/eslint-config`\n","isInternal":false,"tokens":1171,"sizeBytes":4389},{"name":"CLAUDE.md","path":"packages/joint-react/CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-react/CLAUDE.md","title":"Joint-react Skill","category":"anthropic-skill","format":"markdown","content":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with\ncode in this repository.\n\n## Project Overview\n\n`@joint/react` is the React bindings library for JointJS. It provides React\ncomponents and hooks for building diagramming applications with JointJS,\nrendering diagram elements as React components via SVG foreignObject portals.\n\n**Stack:** TypeScript 5.9, React 19 (peer: >=18), Rollup + esbuild (build), Vite\n(storybook/dev), Jest 30 + @testing-library/react (testing), ESLint 9 flat\nconfig, Storybook 10\n\n## Common Commands\n\n```bash\n# Build (Rollup + esbuild → dist/cjs, dist/esm, dist/types)\nyarn build\n\n# Run all checks (typecheck + knip + jest, once against React 19 and once\n# against React 18)\nyarn test\n\n# Run individual checks\nyarn typecheck # tsc --noEmit\nyarn lint # ESLint\nyarn lint-fix # ESLint with auto-fix\nyarn jest # Jest tests only\n\n# Run a single test file\nyarn jest --testPathPatterns=\"use-elements\"\n\n# Run tests in watch mode\nyarn jest --watch\n\n# Storybook (dev server on :6006)\nyarn storybook\n\n# Build storybook\nyarn build-storybook\n```\n\n## Changesets\n\nReleasable changes need a changeset - the format is defined in the **Changeset\nformat** section of the repository's `CONTRIBUTING.md`. Two things are specific\nto this package:\n\n- The changelog scope is the exported component or hook rather than a JointJS\n namespace - components as JSX tags, hooks by name:\n\n ```markdown\n - fix the visual grid to redraw reactively when `drawGrid` changes\n useCells - fix ghost cells reported after `resetCells()`\n ```\n\n- `@joint/react` is versioned independently. It is not part of the\n `@joint/core` linked group, and because it depends on core via `workspace:^`,\n a `@joint/core` minor release does not drag it along - only a major does.\n\n# Clean Code & Style Guidelines\n\n## General\n\n- Prefer clear, explicit code over clever one-liners. Maintainability > brevity.\n- When editing existing code, preserve the existing style unless I explicitly\n ask for a refactor.\n- Leave code cleaner than you found it. Continuously refactor small things\n instead of accumulating technical debt.\n\n## Constants Over Magic Numbers\n\n- Replace hard-coded values with named constants.\n- Use descriptive constant names that explain the value's purpose.\n- Keep constants at the top of the file\n\n## Meaningful Names\n\n- Variables, functions, and classes should reveal their purpose.\n- Names should explain **why** something exists and **how** it is used.\n- Avoid abbreviations unless they are truly universal (e.g. `id`, `URL`,\n `HTML`).\n- Boolean names must be self-descriptive and read like conditions:\n - Use prefixes: `is`, `has`, `should`, `can`, `must`, `needs` (e.g. `isOpen`,\n `hasError`, `shouldRetry`).\n - Avoid generic names like `flag`, `ok`, `state`, `enabled` without context.\n- Function names should describe behavior, not implementation details.\n\n## File Naming (TypeScript / JavaScript)\n\n- All `.ts`, `.tsx`, `.js`, `.jsx` files must use **kebab-case**:\n - Examples: `user-profile.ts`, `something-table.tsx`\n- React component files:\n - File name: kebab-case (e.g. `user-profile-card.tsx`).\n - Component name inside: `PascalCase` (e.g. `UserProfileCard`).\n\n## Smart Comments\n\n- Do **not** comment on what the code does if the code can be made\n self-explanatory instead.\n- Prefer to improve the code so it reads clearly without comments.\n- Use comments to explain:\n - Why something is done in a non-obvious way.\n - Important constraints, assumptions, or business rules.\n - Non-obvious side effects.\n- Document APIs, complex algorithms, and tricky edge cases.\n\n## Single Responsibility\n\n- Each function should do exactly one thing.\n- Functions should be small and focused.\n- If a function needs a long comment to explain what it does, consider\n splitting it into smaller functions.\n- JSDoc is mandatory for all exported functions.\n\n## DRY (Don't Repeat Yourself)\n\n- Extract repeated code into reusable functions or utilities.\n- Share common logic through proper abstractions.\n- Maintain single sources of truth for configuration, constants, and shared\n logic.\n\n## Clean Structure\n\n- Keep related code together.\n- Organize code in a logical hierarchy (modules, domains, features).\n- Use consistent file and folder naming conventions.\n- Avoid \"god\" files that own too many responsibilities.\n\n## Encapsulation\n\n- Hide implementation details behind clear interfaces.\n- Expose only what is needed from a module.\n- Move nested conditionals or complex logic into well-named helper functions.\n\n## TypeScript\n\n- Never use `any` in new code:\n - Prefer proper types, generics, unions, or `unknown` + narrowing.\n - If `any` is unavoidable at a boundary (e.g. 3rd-party library), isolate it\n and add a clear `TODO` explaining why.\n- Write `strict`-friendly code:\n - No implicit `any`.\n - Avoid sloppy or unnecessary `as` casts.\n - Avoid `as any` and non-null assertions (`!`) unless absolutely necessary;\n justify them with a short comment.\n- Use `interface`/`type` aliases for data structures instead of loose objects.\n- Keep function signatures explicit and well-typed, especially for exported\n functions and public APIs.\n- Prefer readonly/immutable data where reasonable (e.g. `readonly` props, avoid\n mutating function arguments).\n\n## Performance Mindset\n\n- Avoid unnecessary allocations and copies:\n - No pointless spreading (`{ ...obj }`) or `JSON.parse(JSON.stringify(...))`\n in hot paths.\n- Avoid creating new functions/objects inside tight loops or very frequently\n rendered components unless memoized.\n- Use `useMemo` / `useCallback` **only** when they prevent real, recurring work\n or re-renders, not everywhere by default.\n- Be careful not to introduce extra re-renders by changing prop shapes\n unnecessarily.\n- Prefer algorithmic improvements and proper data structures over\n micro-optimizations when performance is a concern.\n\n## Code Quality Maintenance\n\n- Refactor continuously in small, safe steps.\n- Fix technical debt early when you touch a piece of code.\n- Prefer explicit, predictable behavior over clever tricks.\n- Keep the codebase internally consistent.\n\n## Testing & Safety\n\n- For non-trivial logic changes, prefer adding or updating tests.\n- Write tests before fixing bugs when possible (regression tests).\n- Keep tests readable, deterministic, and maintainable.\n- Test edge cases, error conditions, and boundary values.\n- Avoid relying on implementation details; test behavior and contracts.\n- Performance is must have, so test it.\n","isInternal":false,"tokens":1532,"sizeBytes":6603},{"name":"README.md","path":"packages/joint-cli/README.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-cli/README.md","title":"joint-cli Documentation","category":"plugin-manifest","format":"markdown","content":"# @joint/cli\n\nCommand-line tool for [JointJS](https://jointjs.com).\n\n## Quick Start\n\n```bash\nnpx @joint/cli list\nnpx @joint/cli download kitchen-sink/js\n```\n\n## Installation\n\n```bash\nnpm install -g @joint/cli\n```\n\nOnce installed globally, the `joint` command is available:\n\n```bash\njoint list\njoint download kitchen-sink/js\n```\n\n## Commands\n\n### `joint list`\n\nList available examples from the [joint-demos](https://github.com/clientIO/joint-demos) repository.\n\n```bash\njoint list\n```\n\n### `joint download [dest]`\n\nDownload an example into the current working directory.\n\n```bash\n# Downloads into ./kitchen-sink-js/\njoint download kitchen-sink/js\n\n# Downloads into ./my-app/\njoint download kitchen-sink/js my-app\n\n# Downloads into the current directory (must be empty or use --force)\njoint download kitchen-sink/js .\n```\n\nIf the destination directory already exists, use `--force` to overwrite:\n\n```bash\njoint download kitchen-sink/js --force\njoint download kitchen-sink/js . --force\n```\n\n## Options\n\n| Option | Description |\n|---|---|\n| `--help`, `-h` | Show help message |\n| `--version`, `-v` | Show version number |\n| `--owner ` | GitHub repo owner (default: `clientIO`) |\n| `--branch ` | GitHub repo branch (default: `main`) |\n| `--force` | Overwrite existing files when downloading |\n\n### Working with forks\n\nUse `--owner` and `--branch` to list and download examples from a fork:\n\n```bash\njoint list --owner myGitHubUser\njoint download kitchen-sink/js --owner myGitHubUser --branch dev\n```\n\n## Environment Variables\n\n| Variable | Description |\n|---|---|\n| `GITHUB_TOKEN` | Optional GitHub token to avoid API rate limiting |\n\n## Requirements\n\n- Node.js >= 22\n- Git\n","isInternal":false,"tokens":431,"sizeBytes":1688},{"name":"README.md","path":"packages/joint-core/demo/custom-embedding/README.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-core/demo/custom-embedding/README.md","title":"custom-embedding Documentation","category":"plugin-manifest","format":"markdown","content":"# JointJS Custom Embedding Demo\n\n## Setup\n\nUse Yarn to run this demo.\n\nYou need to build *JointJS* first. Navigate to the root folder and run:\n```bash\nyarn install\nyarn run build\n```\n\nThen navigate to this directory and open `index.html` in your browser:\n```bash\nopen index.html\n```\n\n## License\n\nThe *JointJS* library is licensed under the [Mozilla Public License 2.0](https://github.com/clientIO/joint/blob/master/LICENSE).\n\nCopyright © 2013-2026 client IO\n","isInternal":false,"tokens":120,"sizeBytes":459},{"name":"README.md","path":"packages/joint-core/demo/custom-shapes/README.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-core/demo/custom-shapes/README.md","title":"custom-shapes Documentation","category":"plugin-manifest","format":"markdown","content":"# JointJS Custom Shapes Demo\n\n## Setup\n\nUse Yarn to run this demo.\n\nYou need to build *JointJS* first. Navigate to the root folder and run:\n```bash\nyarn install\nyarn run build\n```\n\nNavigate to this directory, then run:\n```bash\nyarn install\nyarn start\n```\n\n## License\n\nThe *JointJS* library is licensed under the [Mozilla Public License 2.0](https://github.com/clientIO/joint/blob/master/LICENSE).\n\nCopyright © 2013-2026 client IO\n","isInternal":false,"tokens":116,"sizeBytes":431},{"name":"README.md","path":"packages/joint-core/demo/devs/README.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-core/demo/devs/README.md","title":"devs Documentation","category":"plugin-manifest","format":"markdown","content":"The **Devs** demo introduces a ready-to-use shape with predefined input & output port groups and simplified API.\n\n### joint.shapes.devs.Model\n\nThe Model shape implements simple API on top of the JointJS built-in ports. It splits ports into two semantic groups (**in** and **out**) and adds convenient methods for adding and removing ports.\n\n| Attribute | Description |\n| --- | --- |\n| inPorts | an array of all input ports |\n| outPorts | an array of all output ports |\n\n##### shapes.devs.Model.addInPort\n\n element.addInPort(port, [opt])\n\nAdd a single port into the \\`inPorts\\` array, where \\`port\\` is a name of the port.\n\n##### shapes.devs.Model.addOutPort\n\n element.addOutPort(port, [opt])\n\nAdd a single port into the \\`outPorts\\` array, where \\`port\\` is a name of the port.\n\n##### shapes.devs.Model.changeInGroup\n\n element.changeInGroup(properties, [opt])\n\nChange the settings for the input ports, where \\`properties\\` is an object with a [group configuration](https://resources.jointjs.com/docs/jointjs/v3.7/joint.html#dia.Element.ports.interface). It extends the previous settings with the new configuration by default. Pass `{ rewrite: true }` via `opt` to invalidate the previous settings.\n\n##### shapes.devs.Model.changeOutGroup\n\n element.changeOutGroup(properties, [opt])\n\nChange the settings for the output ports, where \\`properties\\` is an object with a [group configuration](https://resources.jointjs.com/docs/jointjs/v3.7/joint.html#dia.Element.ports.interface). It extends the previous settings with the new configuration by default. Pass `{ rewrite: true }` via `opt` to invalidate the previous settings.\n\n##### shapes.devs.Model.removeInPort\n\n element.removeInPort(port, [opt])\n\nRemove a port from an element from the \\`inPorts\\` array, where \\`port\\` is a name of the port.\n\n##### shapes.devs.Model.removeOutPort\n\n element.removeOutPort(port, [opt])\n\nRemove a port from an element from the \\`outPorts\\` array, where \\`port\\` is a name of the port.\n\n### joint.shapes.devs.Link\n\nThe `devs.Link` extends the `joint.shapes.standard.Link` and changes the link appearance.\n\n#### Example usage\n\n const shape = new joint.shapes.devs.Model({\n position: {\n x: 100,\n y: 100\n },\n inPorts: ['in1', 'in2'],\n outPorts: ['out1', 'out2']\n });\n\n shape.addTo(graph);\n\n // adding/removing ports dynamically\n shape.addInPort('in3');\n shape.removeOutPort('out1').addOutPort('out3');\n\n const link = new joint.shapes.devs.Link({\n source: {\n id: shape.id,\n port: 'out3'\n },\n target: {\n x: 200,\n y: 300\n }\n });\n link.addTo(graph);\n\n // moving the input ports from `left` to `top`\n shape.changeInGroup({ position: 'top' });\n // moving the output ports 'right' to 'bottom'\n shape.changeOutGroup({ position: 'bottom' });\n\n\n#### Hierarchical diagrams\n\nThere are two more shapes designed for hierarchical diagrams as part of the demo - `devs.Atomic` and `devs.Coupled`. They inherit from the `devs.Model` and differ only in the color and size. The purpose of these shapes is to enable you to implement a custom logic in your application based on their type. For instance a `devs.Coupled` can embed `devs.Atomic`'s but not the other way round as shown in the demo below.\n\nWhen working with hierarchical diagrams there is a few methods, that might come in handy.\n\n[`coupled.embed(atomic)`](https://resources.jointjs.com/docs/jointjs/v3.7/joint.html#dia.Element.prototype.embed) that can put the \\`atomic\\` shape into the \\`coupled\\`.\n\n[`coupled.fitToChildren()`](https://resources.jointjs.com/docs/jointjs/v3.7/joint.html#dia.Element.prototype.fitToChildren) that resizes the \\`coupled\\` shape such that all embedded elements are visually contained within it.\n\n[`link.reparent()`](https://resources.jointjs.com/docs/jointjs/v3.7/joint.html#dia.Link.prototype.reparent) that finds the best parent for the \\`link\\` based on the source and target element.\n","isInternal":false,"tokens":977,"sizeBytes":4017},{"name":"README.md","path":"packages/joint-core/demo/elk/README.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-core/demo/elk/README.md","title":"elk Documentation","category":"plugin-manifest","format":"markdown","content":"# JointJS Eclipse Layout Kernel Graph Demo\n\n## Setup\n\nUse Yarn to run this demo.\n\nYou need to build *JointJS* first. Navigate to the root folder and run:\n```bash\nyarn install\nyarn run build\n```\n\nNavigate to this directory, then run:\n```bash\nyarn install\nyarn start\n```\n\n## License\n\nThe *JointJS* library is licensed under the [Mozilla Public License 2.0](https://github.com/clientIO/joint/blob/master/LICENSE).\n\nCopyright © 2013-2026 client IO\n","isInternal":false,"tokens":118,"sizeBytes":445},{"name":"README.md","path":"packages/joint-core/demo/rough/README.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-core/demo/rough/README.md","title":"rough Documentation","category":"plugin-manifest","format":"markdown","content":"# JointJS RoughJS Demo\n\n## Setup\n\nUse Yarn to run this demo.\n\nYou need to build *JointJS* first. Navigate to the root folder and run:\n```bash\nyarn install\nyarn run build\n```\n\nNavigate to this directory, then run:\n```bash\nyarn install\n```\n\nThen open `index.html` in your browser:\n```bash\nopen index.html\n```\n\n## License\n\nThe *JointJS* library is licensed under the [Mozilla Public License 2.0](https://github.com/clientIO/joint/blob/master/LICENSE).\n\nCopyright © 2013-2026 client IO\n","isInternal":false,"tokens":131,"sizeBytes":483},{"name":"README.md","path":"packages/joint-core/demo/ts-demo/README.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-core/demo/ts-demo/README.md","title":"ts-demo Documentation","category":"plugin-manifest","format":"markdown","content":"# JointJS TypeScript Demo\n\n## Setup\n\nUse Yarn to run this demo.\n\nYou need to build *JointJS* first. Navigate to the root folder and run:\n```bash\nyarn install\nyarn run build\n```\n\nNavigate to this directory, then run:\n```bash\nyarn install\nyarn start\n```\n\n## License\n\nThe *JointJS* library is licensed under the [Mozilla Public License 2.0](https://github.com/clientIO/joint/blob/master/LICENSE).\n\nCopyright © 2013-2026 client IO\n","isInternal":false,"tokens":115,"sizeBytes":428},{"name":"README.md","path":"packages/joint-core/demo/vuejs/README.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-core/demo/vuejs/README.md","title":"vuejs Documentation","category":"plugin-manifest","format":"markdown","content":"# JointJS VueJS Demo\n\n## Setup\n\nUse Yarn to run this demo.\n\nYou need to build *JointJS* first. Navigate to the root folder and run:\n```bash\nyarn install\nyarn run build\n```\n\nNavigate to this directory, then run:\n```bash\nyarn install\n```\n\nThen open `index.html` in your browser:\n```bash\nopen index.html\n```\n\n## License\n\nThe *JointJS* library is licensed under the [Mozilla Public License 2.0](https://github.com/clientIO/joint/blob/master/LICENSE).\n\nCopyright © 2013-2026 client IO\n","isInternal":false,"tokens":131,"sizeBytes":481},{"name":"README.md","path":"packages/joint-core/README.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-core/README.md","title":"joint-core Documentation","category":"plugin-manifest","format":"markdown","content":"# JointJS — The JavaScript diagramming library you don't replace at scale\n\n[JointJS](https://jointjs.com) is a proven JavaScript/TypeScript diagramming library for building complex, production-scale diagramming applications.\n\nTeams use it to build AI workflow builders, flowchart and process editors, BPMN modelers, SCADA/HMI and monitoring dashboards, data modeling tools, energy network diagrams, electronic design tools, and org chart builders.\n\nJointJS is framework-agnostic, with first-class support for React.\n\n[](https://user-images.githubusercontent.com/3967880/200360293-808f148c-32af-4f46-bec1-b4ae4e1592a0.jpg)\n\nFurther information, examples and documentation can be found at [jointjs.com](https://jointjs.com).\n\n- 🚀 [Getting started guide](https://docs.jointjs.com)\n- 💡 Ask a question or share feedback in our [GitHub discussions](https://github.com/clientIO/joint/discussions)\n- 🖊️ [180+ demo apps](https://www.jointjs.com/demos) to kickstart your development\n- 🤖 [MCP server integration](https://mcp.jointjs.com/mcp) for AI coding agents\n- ⚛️ **New:** [JointJS for React](https://www.jointjs.com/react-diagrams) — build diagramming UIs in your React app\n\n## Use cases\n\nJointJS is used to build production diagramming applications across many domains:\n\n| Domain | Examples |\n|---|---|\n| Workflow & process | Flowchart editors, process automation, activity and sequence diagrams |\n| AI workflow builders | Node-based AI pipeline and agent builders, marketing automation studios |\n| BPMN | Business process modelers, swimlanes, Visio BPMN import/export |\n| Data modeling | ER diagrams, database schema designers, data mapping tools |\n| UML & software modeling | Class, sequence, statechart and use-case diagrams |\n| Industrial / SCADA & HMI | P&ID diagrams, monitoring and control dashboards |\n| Energy networks | Power and telecom network diagrams, DWDM circuits |\n| Electronic design | Logic circuits, wiring and cable diagrams |\n| Org charts | Organizational charts, hierarchy and tree builders |\n| Timelines | Project and milestone timelines, Gantt and PERT charts |\n\nExplore all [180+ demo apps](https://www.jointjs.com/demos) that serve as boilerplates for your project.\n\n## Framework integrations\n\nJointJS is framework-agnostic and works with any frontend stack. React has first-class, native support; the others have integration guides and examples:\n\n- [**React**](https://docs.jointjs.com/react) — native components and hooks (JointJS for React)\n- [Angular](https://docs.jointjs.com/learn/integration/angular/)\n- [Vue](https://docs.jointjs.com/learn/integration/vue)\n- [Svelte](https://docs.jointjs.com/learn/integration/svelte)\n- [Salesforce Lightning](https://docs.jointjs.com/learn/integration/lightning)\n\n## Features\n\n- essential diagram elements (rect, circle, ellipse, text, image, path)\n- ready-to-use diagram elements of well-known diagrams (ERD, Org chart, FSA, UML, PN, DEVS, ...)\n- custom diagram elements based on SVG or programmatically rendered\n- connecting diagram elements with links or links with links\n- customizable links, their arrowheads and labels\n- configurable link shapes (anchors, connection points, vertices, routers, connectors)\n- custom element properties and data\n- import/export from/to JSON format\n- customizable element ports (look and position, distributed around shapes or manually positioned)\n- rich graph API (traversal, dfs, bfs, find neighbors, predecessors, elements at point, ...)\n- granular interactivity\n- hierarchical diagrams (containers, embedded elements, child-parent relationships)\n- element & link tools (buttons, status icons, tools to change the shape of links, ...)\n- highlighters (provide visual emphasis to your elements)\n- automatic layouts (arrange the elements and links automatically)\n- highly event driven (react on any event that happens inside the diagram)\n- zoom in/out\n- touch support\n- MVC architecture\n- SVG based\n- ... a lot more\n\n## Using JointJS with AI coding agents\n\nJointJS is built to work well with AI-assisted development.\n\n**MCP server** — connect your AI coding agent (Claude Code, Cursor, and other MCP-compatible tools) to the JointJS Model Context Protocol server so it can search the official docs and demos while you build.\n\n```\nhttps://mcp.jointjs.com/mcp\n```\n\nExposes `search_docs` and `search_demos` so your agent writes correct JointJS code against the real API instead of guessing.\n\n## Supported browsers\n\n- Latest Google Chrome (including mobile)\n- Latest Firefox\n- Latest Safari (including mobile)\n- Latest Microsoft's Edge\n- Latest Opera\n\n## Commercial version\n\nThe open-source library covers core diagramming. **[JointJS+](https://www.jointjs.com/jointjs-plus)** adds production-ready plugins (stencils, inspectors, toolbars, advanced layouts, import/export, and more), professional demo apps (including source code), JointJS for React, and direct support from the team that builds the library. [Start a free 30-day trial.](https://www.jointjs.com/free-trial)\n\n## Development Environment\n\nIf you want to work on *JointJS* locally, use the following guidelines to get started.\n\n### Dependencies\n\nMake sure you have the following dependencies installed on your system:\n\n- [Node.js](https://nodejs.org/)\n- [grunt-cli](http://gruntjs.com/using-the-cli)\n- [git](https://git-scm.com/)\n- [yarn](https://yarnpkg.com/getting-started/install)\n\nThe installation requires Node version 22.14.0, to avoid syntax errors during installation.\n\nMake sure that you are using Yarn version >= 2.0.0, so that you have access to [Yarn workspace ranges](https://yarnpkg.com/features/workspaces#workspace-ranges-workspace) functionality. If you are using [Volta](https://volta.sh/), it will automatically read this restriction from `package.json`.\n\n### Setup\n\nClone this git repository:\n\n```\ngit clone https://github.com/clientIO/joint.git\n```\n\nNavigate to the `joint` directory:\n\n```\ncd joint\n```\n\nInstall all dependencies:\n\n```\nyarn install\n```\n\nGenerate distribution files from the source code:\n\n```\nyarn run dist\n```\n\nYou are now ready to browse our example applications, which combine functionality from multiple JointJS packages:\n\n```\ncd examples\n```\n\nRefer to each application's `README.md` file for additional instructions.\n\nYou can also browse the demo applications of our JointJS Core package:\n\n```\ncd packages/joint-core/demo\n```\n\nMost demos can be run by simply opening the `index.html` file in your browser. Some demos have additional instructions, which you can find in their respective `README.md` files.\n\n### Tests\n\nTo run all tests:\n\n```\nyarn run test\n```\n\nTo run only the server-side tests:\n\n```\nyarn run test-server\n```\n\nTo run only the client-side tests:\n\n```\nyarn run test-client\n```\n\nTo run only TypeScript tests:\n\n```\nyarn run test-ts\n```\n\n### Lint\n\nTo check for linting errors in `src` and `types` directories:\n\n```\nyarn run lint\n```\n\nTo auto fix errors, run eslint for `src` and `types` directories:\n\n```\nyarn run lint-fix\n```\n\n### Code Coverage Reports\n\nTo output a code coverage report in HTML:\n\n```\nyarn run test-coverage\n```\n\nTo output a code coverage report in [lcov format](http://ltp.sourceforge.net/coverage/lcov/geninfo.1.php):\n\n```\nyarn run test-coverage-lcov\n```\n\nThe output for all unit tests will be saved in the `packages/joint-core/coverage` directory.\n\n## Contributors\n\n[](https://github.com/clientIO/joint/graphs/contributors)\n\n## License\n\nThe *JointJS* library is licensed under the [Mozilla Public License 2.0](https://github.com/clientIO/joint/blob/master/LICENSE).\n\nCopyright © 2013-2026 client IO\n","isInternal":false,"tokens":1835,"sizeBytes":7723},{"name":"README.md","path":"packages/joint-decorators/README.md","rawUrl":"https://raw.githubusercontent.com/clientIO/joint/HEAD/packages/joint-decorators/README.md","title":"joint-decorators Documentation","category":"plugin-manifest","format":"markdown","content":"# JointJS Decorators\n\nECMAScript / TypeScript decorator for defining *[JointJS](https://www.jointjs.com/)* shapes.\n\nThis library fully depends on [JointJS](https://github.com/clientio/joint) (*>=3.5*), so please read its README before using this library.\n\n## Setup\n\nEnable the [experimentalDecorators](https://www.typescriptlang.org/docs/handbook/decorators.html) compiler option in your `tsconfig.json`.\n\nThen install JointJS Decorators from NPM:\n```bash\nnpm i -S @joint/decorators\n```\n\n## License\n\n[Mozilla Public License 2.0](https://www.mozilla.org/en-US/MPL/2.0/)\n\n## Usage\n\nThere are a few class decorators:\n\n- [`@Model`](#Model)\n- [`@View`](#View)\n\nAnd several class member decorators:\n\n- [`@Function`](#Function)\n- [`@On`](#On)\n- [`@SVGAttribute`](#SVGAttribute)\n\n---\n\n## @Model(options: ModelOptions)\n\nThe decorator allows you to:\n- paste an existing SVG and use it as the model's markup\n- keep your SVG attributes in sync with your model's attributes\n- transform data using functions\n- introduce a new SVG attribute or change the behavior of an existing one\n\n```ts\nimport { dia } from '@joint/core';\nimport { Model } from '@joint/decorators';\n\n@Model({\n```\n```handlebars\n template: `\n \n \n {{firstName}} {{lastName}}\n