9da3b7479f
Some checks are pending
CI: Master (Build, Test, Lint) / Build for Github Cache (push) Waiting to run
CI: Master (Build, Test, Lint) / Unit tests (24.18.1) (push) Waiting to run
CI: Master (Build, Test, Lint) / Unit tests (26.5.1) (push) Waiting to run
CI: Master (Build, Test, Lint) / Lint (push) Waiting to run
CI: Master (Build, Test, Lint) / Performance (push) Waiting to run
CI: Master (Build, Test, Lint) / Verify single-instance deps (npm-install) (push) Waiting to run
CI: Master (Build, Test, Lint) / Notify Slack on failure (push) Blocked by required conditions
Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> |
||
|---|---|---|
| .. | ||
| insights/frontend | ||
| instance-registry/frontend | ||
| otel/frontend | ||
| README.md | ||
Modules
Feature modules carved out of packages/frontend/editor-ui. Each one is a workspace package at
<name>/frontend: source-only (main: "src/index.ts", no dist), consumed by the editor-ui shell
through Vite aliases.
<name>/backend is a reserved path rather than a workspace package — the backend runtime discovers
modules under packages/cli/src/modules/<name>. The extra nesting level is what lets both halves of
a module sit together later.
packages/modules itself stays tracked even when it holds nothing: turbo rejects a --filter
whose directory does not exist.
CI splits the two halves by path. The frontend jobs select packages/modules/*/frontend. The backend
jobs exclude that same path instead of all of packages/modules, so a <name>/backend package gets
backend CI on the day it appears. Both filters live in the root test:ci:* scripts and in the two
backend jobs in .github/workflows/test-unit-reusable.yml.