[data-reveal]{opacity:1!important;transform:none!important}
Supported releases
Frontend

Supported releases

Declare the @antelopejs/dms-frontend releases a module runs on, and what the CLI does with that range.

A frontend module names the @antelopejs/dms-frontend releases it runs on in its own package.json, the way a package names the Node.js versions it supports:

package.json
{
  "name": "@acme/dms-billing-frontend-vue",
  "engines": {
    "@antelopejs/dms-frontend": ">=0.6.0 <0.7.0"
  }
}

What the CLI checks

prepare, dev, build and verify-source read the range before they generate anything, whether the manifest was just fetched or replayed from the cache, and stop when this release falls outside a module's range. The message names each such module, its range and this release, rather than letting the build, the type check or a render fail later on an API the release no longer has, or does not have yet:

$ ajs dms prepare -b http://localhost:5050 --strict
ajs dms prepare  http://localhost:5050
✖ These frontend modules do not run on @antelopejs/dms-frontend 0.6.1
  template-dms-demo-frontend-vue (./frontend-vue) supports >=0.5.0 <0.6.0
  → Install a @antelopejs/dms-frontend release in their ranges, or upgrade the modules
  • dev, build and verify-source exit 1. prepare warns and exits 0, as it does for any setup it cannot complete, unless --strict is given.
  • A prerelease is checked as the release it leads to: 0.4.0-next.1 is outside <0.4.0.
  • A module that declares no range still loads, and a warning names it once per workspace.
  • start checks nothing: it runs what build produced.

Choosing the range

Cap the range below the next breaking release, which is the next minor release while this package is below 1.0, and widen it once the module has been checked against that release. A range left open to <1.0.0 admits the very release that removes something the module calls. The DMS ranges are listed in the Compatibility table.

A module also raises the floor of its range when it starts using something a release added, such as a dms.server.ts: an older loader never reads the file.

Why an engine and not a peer dependency

The generated workspace installs every module as a workspace package, and pnpm installs a workspace package's peer dependencies, optional ones included, so a peer dependency on the loader would pull a copy of it into every workspace. Package managers ignore an engine they do not know, and so does a loader released before this check, which arrived in 0.3.3.