The DMS interface

Overview

The DMS ships one public AntelopeJS interface package, @antelopejs/interface-dms. Everything a module needs to declare pages, build components, authenticate a request, send a notification or render an HTML template comes from that single package, through a subpath named after the domain it belongs to. Never reach the surface through the runtime package @antelopejs/dms.

{
  "dependencies": {
    "@antelopejs/interface-dms": ">=0.0.1 <1.0.0"
  }
}

This section is the contract reference: the exact symbol names, options and return types, grouped by domain. The DMS guide covers the same ground task by task, organised around what you are building.

If you are learning the DMS, start with the Quickstart and Pages & components. Return here when you need an import path, a signature, or the exact behavior of an option; you do not need to read every domain before building a page.

Separately published extension interfaces have their own module interface references, including Builder. This page covers @antelopejs/interface-dms itself.

One installed copy

The host and every module must resolve the same installed copy of @antelopejs/interface-dms. The package holds live state, not just types: the page, category and extension registries, the permission tree, the hook registry, the data-type and block registries and the component slot resolvers. A second copy gets its own empty registries: pages register into a tree nobody reads, permissions never reach the roles form, and hooks never fire, without any error. @antelopejs/core checks this before constructing modules and fails with Incompatible interface package resolution when a module resolves another copy.

Depend on the package with a wide range, raising the lower bound to the version you need rather than pinning an upper one, so package managers can deduplicate, and never vendor or bundle it into a module. @antelopejs/dms, which implements the interface, is the exception: it caps its range below the next minor, so a breaking minor never reaches an older DMS.

The runtime also hands a module a per-context view of the values it receives through an interface, so reference equality does not survive the round trip. Compare registrations on a field, never with ===, and compare plain data rather than the views themselves: isDeepStrictEqual and assert.deepStrictEqual refuse two views that hold equal values.

The Domains

Start with Core and Base: the first declares pages and the components they carry as serializable data, the second is the concrete set of components you fill those pages with. Auth resolves a request to a user, which the permission and tenant guards build on. The remaining two stand on their own and are used where you need them.

Subpath Map

Each subpath is its own entry point: importing one does not pull the others in, and the modules that register schemas or controllers as they evaluate are deliberately kept off the root barrel. Every domain's introduction carries the detailed map of its own subpaths; this is the whole set at a glance.

Beyond these entry points, built files are importable through the ./* export (@antelopejs/interface-dms/base/form-types). Moving or renaming a public path is a breaking change, like removing an export.

Importability does not make a declaration public. Paths under internal/, symbols tagged @internal, and internal namespaces are wiring between the interface and its implementation, not supported consumer APIs. This includes compatibility exports retained at old paths. Public types named by a supported signature remain part of its contract; use the documented entry points rather than calling internal proxies or raw writer helpers.

How to Read a Domain

Every domain folder opens with 1.introduction.md. It gives you the overview, the key features, the AntelopeJS packages the domain depends on, one runnable quick-start example, and the list of the folder's other pages.

The numbered pages after it are topic pages, ordered so that reading them front to back builds up. Each one starts with an overview, then works through the surface task by task with a code example per section and a table for anything that takes options. Every topic page ends with a link to the next one, so you can also follow a folder straight through from its introduction.

Read a topic page on its own when you already know which surface you need.