angular/packages/compiler-cli/private
Matthieu Riegler 8e50cdb930 refactor(compiler-cli): Remove deep imports of compiler-cli in angular/core
migration schematics will pull from `compiler-cli/private/migrations`
core tests will pull from `compiler-cli/private/testing`
2025-10-28 15:58:56 +01:00
..
BUILD.bazel refactor(compiler-cli): Remove deep imports of compiler-cli in angular/core 2025-10-28 15:58:56 +01:00
localize.ts refactor: update license text to point to angular.dev (#57901) 2024-09-24 15:33:00 +02:00
migrations.ts refactor(compiler-cli): Remove deep imports of compiler-cli in angular/core 2025-10-28 15:58:56 +01:00
README.md refactor: switch packages away from deep cross-package imports (#43431) 2021-10-01 18:28:43 +00:00
testing.ts refactor(compiler-cli): Remove deep imports of compiler-cli in angular/core 2025-10-28 15:58:56 +01:00
tooling.ts refactor: update license text to point to angular.dev (#57901) 2024-09-24 15:33:00 +02:00

This is a directory defining the @angular/compiler-cli/private entry-point. The entry-point can be used to expose code that is needed by other Angular framework packages, without having to expose code through the primary entry-point.

The primary entry-point has a couple of downsides when it comes to cross-package imports:

  • It exports various other things that will end up creating additional type dependencies. e.g. when the Angular localize package relies on it, it might end up accidentally relying on @types/node.
  • The primary entry-point has a larger build graph, slowing down local development as much more things can invalidate the dependent targets. A smaller subset leads to faster incremental builds.