DGM.js is an infinite canvas where shapes carry scripts and constraints

What makes a shape smart here

The library describes itself as an infinite canvas with smart shapes, and the parenthesis after that is the specification: scripting, constraints and extended properties.

Each of those three changes what a diagram can express. Scripting on a shape means behaviour lives with the object rather than in an event handler outside the document, so a diagram can carry its own logic. Constraints mean relationships between objects are declarative, which is the difference between a diagram that stays arranged and one that does not. Extended properties mean a shape is not limited to the built-in fields, so an application can attach its own data to a node and render from it.

The other capabilities surround that core. Infinite canvas and multi-page support cover the document model, hand-drawn styles cover the visual language, real-time collaboration covers more than one author, and dark mode with adaptive colors means the canvas follows the application theme rather than staying light.

Text and export round out the surface: rich text inside shapes, image export to PNG, JPEG, WebP and SVG, PDF export, and JSON export and import for storage.

Headless components mean the editor and the canvas are separable

The second bullet in the feature list is headless components in React, and that is the architectural decision worth understanding.

A headless component here means the logic is available without the canvas rendering, so an application can mount a piece of the editor's behaviour, its state handling or its commands inside its own UI. That is what lets the same code serve a full-screen canvas, a compact embedded diagram, and a panel that manipulates a selection without a canvas attached.

For a team shipping a product rather than a demo, that is the difference between a library you wrap and one that dictates your layout. A diagram embedded in a form field or a side panel behaves very differently when its controls do not require a rendering surface.

The React dependency is explicit in the feature list, so this is a React library rather than a framework-agnostic one, and anyone considering it in a Vue or Svelte codebase is already out of scope.

A monorepo with packages, apps and TypeDoc at the root

The repository is an npm workspaces monorepo. The root package is a shell whose real content is the workspaces field, which covers packages/* and apps/*, plus typedoc for documentation and TypeScript 5.4 as a dev dependency.

The scripts show the shape of the work. docs runs typedoc, docs-all runs it across every workspace that defines the script, and build-all builds every workspace that defines a build. The test script is a placeholder that echoes an error and exits with status 1, which is worth noticing: this repository does not carry a test suite at the root level, so a contributor validating a change has no automated safety net here.

The build sequence from the README is the practical part:

git clone https://github.com/dgmjs/dgmjs.git
cd dgmjs
npm install
npm run build --workspaces --if-present
npm run dev -w demo

Install, build every workspace that can be built, then run the demo app with the -w flag selecting the demo workspace. The --if-present flags matter: a workspace without a build or docs script is skipped rather than failing the run, which is how the repo tolerates apps and packages with different toolchains.

The npm package published for the core is @dgmjs/core, which is the one to depend on in your own application.

Four applications show what the library is actually for

The showcase section is more informative than the feature list, because these are products rather than bullet points.

Frame0 is described as a sketch-style low-fidelity wireframing tool, which is the sharpest statement of what the smart shape model buys: a wireframe is not a collection of rectangles, it is a layout that keeps its relationships when things move, and constraints are how that survives an edit. DGM App at app.dgmjs.dev is the full-featured web-based sketchnotes application, which is the library exercised as a document editor rather than as a diagram tool.

Nakso is listed as a local-first whiteboard application, and local-first is a demanding case for a canvas library: the document has to round-trip through storage without a server holding it. draw2app generates a web app from a low-fidelity sketch, using OpenAI, which puts the library at the front of an automated pipeline where the canvas is both input and output.

Four applications built on one library, and they span wireframing, notes, offline whiteboards and machine-generated output. That range is the best evidence available about how general the underlying model is.

There is also a minimal example on StackBlitz and a getting started guide.

GPLv3 by default, with a commercial route and no pull requests

The licence needs stating plainly because it is the most consequential fact for an adopter. DGM.js is distributed under GPLv3, and the README adds that if you want a non-GPL licence you should look at the licensing options on the project's site.

So the default grant is strong copyleft and an alternative exists under terms not described in the repository. It also means the question of whether you can use it in a closed-source product should be checked on the licensing options website before you commit.

The contribution policy is the other constraint, and it is unambiguous. The README states the project is not open contribution and that pull requests are not accepted.

That combination, a non-GPL licensing option and no pull requests, describes the project’s contribution and licensing constraints. The last push was on 2026-09-14, and the newest releases are v1.5.3 on 2025-12-01, v1.5.4 on 2025-12-18 and v1.5.5 on 2025-12-26.

Where this sits against building on a plain canvas or a whiteboard service

The realistic alternatives come in two shapes.

The first is to use a plain canvas or SVG drawing library and build the diagram model yourself. That gives you total control and no licence question, and it costs you everything the smart shape layer provides: no declarative constraints, no per-shape scripting, no built-in real-time collaboration, and no document format you did not design. For a diagram editor with a narrow shape vocabulary, that is a defensible trade. For a whiteboard, it is not, because collaboration and document persistence are the expensive parts.

The second is a hosted whiteboard product used as a product. Those give working collaboration and a mature file format immediately, and they take away the ability to make the canvas behave like your own product, which is usually the reason to build one in the first place.

DGM.js sits between those, and its bet is that the shape model is the part worth owning. Real-time collaboration is listed as supported rather than promised, and no documentation of the transport or the conflict resolution is given in the README, so a team whose collaboration requirement is strict should verify that before committing rather than after.

Editorial conclusion

DGM.js fits a team that wants to ship a whiteboard or low-fidelity wireframing product and needs its own file format rather than a hosted tool, since JSON export and import, multi-page support and headless components cover the parts a product needs and a demo does not. It is the wrong dependency if your product will be closed source, because the default licence is GPLv3 and non-GPL terms are a separate arrangement, and it is the wrong project if you want to contribute upstream, since the README states pull requests are not accepted. Before adopting, run npm install and npm run build --workspaces --if-present to confirm the packages build in your Node version, then read the licensing options page rather than assuming the GPL grant is the only route, and look at the showcase applications to judge whether the smart shape model matches the diagrams your users actually draw.

Frequently asked questions

Official sources

1. dgmjs/dgmjs on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases