Skip to content

feat(api): bring the dashboard API into the workspace - #165

Draft
userAugustos wants to merge 3 commits into
mainfrom
feat/api-package
Draft

userAugustos wants to merge 3 commits into
mainfrom
feat/api-package

Conversation

@userAugustos

@userAugustos userAugustos commented Sep 21, 2026

Copy link
Copy Markdown

Fixes CAN-318

Summary

This brings the dashboard API into the monorepo as two TypeScript workspace packages, copied verbatim from the canyon-os checkout at f8be607. packages/api becomes the workspace package @cc-forge/api and packages/tsconfig becomes @cc-forge/tsconfig, the shared base config the API compiles against. No package, identifier, database or container name changes, and no fixes to the copied code.

The tooling those packages need comes with them. The Prettier, oxlint and editor configs land at the repository root. The dev Postgres 17 and Mailpit stack lands under .docker, which is what the end-to-end suite runs against locally. The Docker build-context ignore list lands at the root, extended so the Python side of the repository, the virtual environment and the Homebrew formula stay out of the API image context. The API end-to-end workflow lands at its usual path, with its actions pinned by commit SHA the way the existing CI workflow pins them. The API image definition moves next to the package it builds, at packages/api/Dockerfile, and still builds from the repository root.

The package is wired into the root commands. bun run check now runs the API's lint, type check and format check alongside the three Python tasks. bun run test now runs the API unit tests alongside the CLI, core and root Python suites. bun run build now writes the API's dist alongside the two Python wheels. The root manifest gains the dev dependencies those scripts need and the docker and end-to-end helper scripts, and the lockfile is regenerated.

The second commit realigns the CLI with the environment the API actually reads. The compose file the CLI ships for canyonos serve passed the api service a flag the API no longer reads, and left out the three settings the API insists on when it runs under the published image. The service now names the auth mode, the deploy worker and the file storage provider, matching the self-hosted stack the API is tested against, and a new CLI test holds that contract in place.

Test

  • bun install --frozen-lockfile - no changes, 289 installs checked across 424 packages
  • uv sync --locked - 53 packages checked, and uv lock --check resolves with the lockfile unchanged
  • bun run check - 7 tasks successful: the API lint over 134 files with no warnings, the API type check, the API format check, the API build the type check depends on, and the Python lint, type check and format check over 145 files
  • bun run test - 4 tasks successful: 64 API unit tests, 156 CLI tests, 257 core tests with 1 skipped, 15 root tests
  • bun run build - 3 tasks successful: the API dist plus the CLI and core wheels
  • bun run --filter @cc-forge/api typecheck - exits clean
  • bun run docker:up and bun api:test:e2e - no Docker daemon is reachable in the environment this was prepared in, so the end-to-end suite was not run locally. The workflow runs it on this pull request.
  • The copies are verbatim. Comparing both packages against the source checkout reports only packages/api/Dockerfile, which is new here, and packages/api/package.json, which gains the scripts the root commands call.

Known and accepted

The end-to-end suite runs only in the workflow for now, since the environment this was prepared in has no Docker daemon.

The dashboard web application and the published images come in the next pull request, which is also what restores the dropped manifest copy lines in the image definition.

The CLI stack version is deliberately unchanged. No image is published from this repository yet, so there is nothing new for the version to point at.

The CLI module that manages the stack needed no edit. It never referenced the removed flag, which lived only in the shipped compose file.

@coderabbitai

coderabbitai Bot commented Sep 21, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

- 8025:8025

steps:
- uses: actions/checkout@v4
Move the dashboard API and the shared TypeScript config into this monorepo
as the workspace packages @cc-forge/api and @cc-forge/tsconfig, copied
verbatim from the canyon-os checkout.

Bring the tooling the package needs with it: the Prettier, oxlint and editor
configs at the root, the dev Postgres and Mailpit compose stack under .docker,
the Docker build context ignore list, and the API end-to-end workflow.

Wire the package into the root commands. packages/api/package.json gains lint,
format, format:check and a unit-test script that runs without a local .env, so
bun run check, bun run test and bun run build now cover the API alongside the
Python packages.
The compose file the CLI ships for `canyonos serve` passed the api service
CANYONOS_DISABLE_AUTH, which the API no longer reads, and left out AUTH_MODE
and DEPLOY_WORKER, which it refuses to start without under the image's
NODE_ENV=production. Name AUTH_MODE, DEPLOY_WORKER and FILE_STORAGE instead,
matching the self-hosted stack the API is tested against, and cover the
contract with a test over the shipped manifest.
Only the api's type check needs its own dist, because it resolves the
package's published entry points. On the generic task the dependency reached
the Python packages too and built both wheels on every check.

Drop the docstring on the new CLI manifest test while here; the test name
already says what it asserts.
@userAugustos
userAugustos changed the base branch from ci/release-through-turbo to main September 21, 2026 20:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants