Files
zitadel/console
Elio Bischof b10455b51f chore: reproducible pipeline with dev containers (#10305)
# Which Problems Are Solved

- The previous monorepo in monorepo structure for the login app and its
related packages was fragmented, complicated and buggy.
- The process for building and testing the login container was
inconsistent between local development and CI.
- Lack of clear documentation as well as easy and reliable ways for
non-frontend developers to reproduce and fix failing PR checks locally.

# How the Problems Are Solved

- Consolidated the login app and its related npm packages by moving the
main package to `apps/login/apps/login` and merging
`apps/login/packages/integration` and `apps/login/packages/acceptance`
into the main `apps/login` package.
- Migrated from Docker Compose-based test setups to dev container-based
setups, adding support for multiple dev container configurations:
  - `.devcontainer/base`
  - `.devcontainer/turbo-lint-unit`
  - `.devcontainer/turbo-lint-unit-debug`
  - `.devcontainer/login-integration`
  - `.devcontainer/login-integration-debug`
- Added npm scripts to run the new dev container setups, enabling exact
reproduction of GitHub PR checks locally, and updated the pipeline to
use these containers.
- Cleaned up Dockerfiles and docker-bake.hcl files to only build the
production image for the login app.
- Cleaned up compose files to focus on dev environments in dev
containers.
- Updated `CONTRIBUTING.md` with guidance on running and debugging PR
checks locally using the new dev container approach.
- Introduced separate Dockerfiles for the login app to distinguish
between using published client packages and building clients from local
protos.
- Ensured the login container is always built in the pipeline for use in
integration and acceptance tests.
- Updated Makefile and GitHub Actions workflows to use
`--frozen-lockfile` for installing pnpm packages, ensuring reproducible
installs.
- Disabled GitHub release creation by the changeset action.
- Refactored the `/build` directory structure for clarity and
maintainability.
- Added a `clean` command to `docks/package.json`.
- Experimentally added `knip` to the `zitadel-client` package for
improved linting of dependencies and exports.

# Additional Changes

- Fixed Makefile commands for consistency and reliability.
- Improved the structure and clarity of the `/build` directory to
support seamless integration of the login build.
- Enhanced documentation and developer experience for running and
debugging CI checks locally.

# Additional Context

- See updated `CONTRIBUTING.md` for new local development and debugging
instructions.
- These changes are a prerequisite for further improvements to the CI
pipeline and local development workflow.
- Closes #10276
2025-07-24 14:22:32 +02:00
..

Console Angular App

This is the ZITADEL Console Angular application.

Development

Prerequisites

  • Node.js 18 or later
  • pnpm (latest)

Installation

pnpm install

Proto Generation

The Console app uses dual proto generation with Turbo dependency management:

  1. @zitadel/proto generation: Modern ES modules with @bufbuild/protobuf for v2 APIs
  2. Local buf.gen.yaml generation: Traditional protobuf JavaScript classes for v1 APIs

The Console app's turbo.json ensures that @zitadel/proto#generate runs before the Console's own generation, providing both:

  • Modern schemas from @zitadel/proto (e.g., UserSchema, DetailsSchema)
  • Legacy classes from src/app/proto/generated (e.g., User, Project)

Generated files:

  • @zitadel/proto: Modern ES modules in login/packages/zitadel-proto/
  • Local generation: Traditional protobuf files in src/app/proto/generated/
    • TypeScript definition files (.d.ts)
    • JavaScript files (.js)
    • gRPC client files (*ServiceClientPb.ts)
    • OpenAPI/Swagger JSON files (.swagger.json)

To generate proto files:

pnpm run generate

This automatically runs both generations in the correct order via Turbo dependencies.

Development Server

To start the development server:

pnpm start

This will:

  1. Fetch the environment configuration from the server
  2. Serve the app on the default port

Building

To build for production:

pnpm run build

This will:

  1. Generate proto files (via prebuild script)
  2. Build the Angular app with production optimizations

Linting

To run linting and formatting checks:

pnpm run lint

To auto-fix formatting issues:

pnpm run lint:fix

Project Structure

  • src/app/proto/generated/ - Generated proto files (Angular-specific format)
  • buf.gen.yaml - Local proto generation configuration
  • turbo.json - Turbo dependency configuration for proto generation
  • prebuild.development.js - Development environment configuration script

Proto Generation Details

The Console app uses dual proto generation managed by Turbo dependencies:

Dependency Chain

The Console app has the following build dependencies managed by Turbo:

  1. @zitadel/proto#generate - Generates modern protobuf files
  2. @zitadel/client#build - Builds the TypeScript gRPC client library
  3. console#generate - Generates Console-specific protobuf files
  4. console#build - Builds the Angular application

This ensures that the Console always has access to the latest client library and protobuf definitions.

Legacy v1 API (Traditional Protobuf)

  • Uses local buf.gen.yaml configuration
  • Generates traditional Google protobuf JavaScript classes extending jspb.Message
  • Uses plugins: protocolbuffers/js, grpc/web, grpc-ecosystem/openapiv2
  • Output: src/app/proto/generated/
  • Used for: Most existing Console functionality

Modern v2 API (ES Modules)

  • Uses @zitadel/proto package generation
  • Generates modern ES modules with @bufbuild/protobuf
  • Uses plugin: @bufbuild/es with ES modules and JSON types
  • Output: login/packages/zitadel-proto/
  • Used for: New user v2 API and services

Dependency Management

The Console's turbo.json ensures proper execution order:

  1. @zitadel/proto#generate runs first (modern ES modules)
  2. Console's local generation runs second (traditional protobuf)
  3. Build/lint/start tasks depend on both generations being complete

This approach allows the Console app to use both v1 and v2 APIs while maintaining proper build dependencies.

Legacy Information

This project was originally generated with Angular CLI version 8.3.20 and has been updated over time.