Camunda Console Composite Components

Storybook: Link

Dev

# install
pnpm install

# start storybook
pnpm build-storybook
pnpm start

# build components
pnpm build

Turbo builds the workspace dependencies before C4. Outside Turbo, pnpm build also builds the API and shared-types packages.

Tests

Build the workspace dependencies before the first test run:

pnpm --filter @camunda/ccma-api... build
pnpm --filter @camunda/camunda-composite-components build
pnpm --filter @camunda/ccma-saas-frontend test

The full suite uses up to two isolated fork workers, capped at half the available CPU capacity. A two-core runner uses one worker. The node project runs an explicit list of DOM-free tests without browser setup. All other tests use the dom project with jsdom and the existing browser setup.

For worker benchmarks, override the limit with --maxWorkers=1 or 2:

pnpm --filter @camunda/ccma-saas-frontend test --maxWorkers=2

Release

Bump version in package.json and create a new release. This will start a github action to publish the package to the github package repository.

Pushing to main will update the storybook available under cloudflare page.

Usage

The package has two entry points.

@camunda/ccma-saas-frontend — components and widgets

import { C4WorkflowInformation } from '@camunda/ccma-saas-frontend'

// ...

return (
  <C4WorkflowInformation
    isLoading={true}
    // ...
  />
)

@camunda/ccma-saas-frontend/runtime — the headless data layer

Providers, hooks, SSE and Camunda entity logic, with no presentational dependencies — 14 modules instead of 287, and no Carbon, lucide-react, recharts or react-markdown in the graph. This is the entry point for external consumers that only need the data (e.g. feeding the Camunda Design System navigation components).

import { useC4ClusterNavEntries } from '@camunda/ccma-saas-frontend/runtime'

Every runtime name is exported from both entry points, so importing from the package root still works exactly as before. See docs/runtime.md for the integration guide and for what the subpath does and does not shrink.

Deep imports (@camunda/ccma-saas-frontend/lib/esm/…) still resolve, but are a deprecated compatibility shim scheduled for removal in the next major — they hard-code unversioned internal paths. Use one of the two entry points above.