The Problem
Building Angular applications with the standard ng build toolchain becomes slow and non-hermetic as projects grow. Incremental rebuilds degrade, caching is inconsistent across machines, and the build graph is opaque. This repo demonstrates how to migrate an Angular app to Bazel, Google's build system, to get reproducible, cacheable, and parallelizable builds.
What This Does
This is a fork of the well-known "RealWorld" Angular example app (a Medium clone called Conduit) that has been migrated to Bazel. The core value is the migration itself: WORKSPACE, BUILD.bazel files at the root and in each feature module (src/app/article/BUILD.bazel, src/app/core/BUILD.bazel, etc.), and Bazel-specific config in .bazelrc and .bazelignore. The application logic itself is standard Angular—feature modules for auth, editor, profile, settings, and shared components, with JWT-based auth and a REST API client in src/app/core/services/api.service.ts.
The repo shows how to structure an Angular app for Bazel: each feature module gets its own BUILD.bazel target, which enables fine-grained incremental builds. The src/environments/BUILD.bazel file handles environment-specific configuration, and src/require.config.js and src/rxjsshims.js exist to bridge Angular's dependency management with Bazel's strict sandboxing.
How To Use It
Setup: Install dependencies with Yarn (the repo uses yarn.lock and the README explicitly recommends Yarn). You'll need Angular CLI and Bazel installed globally.
Configuration: No environment variables are strictly required. The API URL is set in src/environments/environment.ts (defaults to the live Conduit API). For a local backend, edit apiurl in that file.
Running it: The README documents two paths. For development, use the standard Angular CLI: ng serve. For a production Bazel build and server:
yarn install ./nodemodules/.bin/bazel run //src:prodserver
The //src:prodserver target is defined in src/BUILD.bazel. Note that the README also mentions ng build for non-Bazel builds, but the Bazel path is the point of this repo.
Real-World Use
This is a reference implementation for teams evaluating Bazel for Angular. A practical workflow: clone the repo, run the Bazel production server, and observe how Bazel caches compiled outputs across rebuilds. For a real migration, you'd replicate the BUILD.bazel structure here—one target per feature module, with tslibrary rules and explicit dependencies—into your own Angular project. The e2e/BUILD.bazel file shows how to wire Protractor tests into the Bazel graph, though the README states testing is "under development."
Code Health & Issues
Med - No LICENSE file - The repo has no license, which makes usage and redistribution rights unclear. This is a blocker for commercial adoption. Med - Test coverage is minimal - Only 4 test files exist, and the README explicitly says testing is under development. The src/test.ts and src/initialize_testbed.ts suggest a test harness exists, but coverage is thin. Low - CI is minimal - .travis.yml exists, but there's no evidence of Bazel-specific CI caching or matrix testing. For a build-system demo, CI coverage of the Bazel path would be expected. Low - Backup config files - tsconfig.json.bak and angular.json.bak suggest an in-progress migration. These should be removed before treating this as a clean reference.
The Bottom Line
This is a useful reference for Angular teams evaluating Bazel, showing a realistic app structure with per-module build targets. It's not a production-ready template—the missing license and thin test coverage limit its use as a starting point. Use it to study the Bazel migration pattern, not as a drop-in foundation.