Testing

A frontend module's code normally runs inside the generated workspace, which supplies its aliases and its server. Three tools bring the same pieces to a module's own test suite and CI.

Layer aliases outside the workspace

Every layer a module ships under layers/<name>/ answers to #<name> inside the generated workspace. That convention is exported, so a module's own tooling reuses it instead of restating it. A unit test that runs the module's Vue sources outside the workspace, where nothing otherwise supplies #dms-core or #dms-ui, gets them from frontendLayerAliases:

import { resolve } from "node:path";
import { frontendLayerAliases } from "@antelopejs/dms-frontend/common";
import { defineConfig } from "vitest/config";

export default defineConfig({
  resolve: {
    alias: frontendLayerAliases(
      resolve(__dirname, ".antelope/cache/@antelopejs/dms/frontend-vue"),
    ),
  },
});

frontendLayerAliases reads a module root on disk and needs no backend, manifest or materialized workspace. frontendLayerTypePaths returns the same layers in the shape of tsconfig paths, and resolveFrontendLayers is the primitive behind both. Pass several module roots in increasing precedence to overlay them: when two modules expose a layer with the same name, the last one wins, which is the order the loader materializes them in.

Module routes

serveModuleRoutes, from @antelopejs/dms-frontend/templates/vue/server/module-testing.mjs, serves the default export of a module's dms.server.ts on a local port, through the same router, event and cookie jar as the frontend server. A test calls the routes over HTTP and checks their answers, cookies included.

In CI

ajs dms verify-source builds and type-checks the module against this loader release and the DMS core layer the project installs, renders the DMS e-mail templates, and checks the bundles, all without a backend. Run it in the module's CI next to its unit tests.

A CI type check that needs the generated types against a running backend uses ajs dms prepare --strict.