angular/packages/compiler-cli/private
Paul Gschwendtner b7c5645f05 build: migrate packages/compiler-cli to ts_project (#61826)
This commit migrates the remaining pieces of `compiler-cli` to
`ts_project`. This involves a few more things during migration:

- the `ng_module` ngc_wrapped rule broke as part of this change, so we
  switched it to `ts_project` too. This logic is soon gone anyway.

- we needed an extra pnpm "package.json" for the linker babel test. This test is
  loading from the real compiler-cli npm package. Babel needs a real
  node module for this, so this solution seems reasonable. It may be
  worth exploring in the future to move this test into an integration
  test though.

- the older integrationtest in compiler-cli is removed as the coverage
  is much better with the compliance test suite and this test.

PR Close #61826
2025-06-03 11:41:52 +02:00
..
bazel.ts refactor: update license text to point to angular.dev (#57901) 2024-09-24 15:33:00 +02:00
BUILD.bazel build: migrate packages/compiler-cli to ts_project (#61826) 2025-06-03 11:41:52 +02:00
localize.ts refactor: update license text to point to angular.dev (#57901) 2024-09-24 15:33:00 +02:00
migrations.ts build: properly compile tests in core with Angular compiler (#60268) 2025-03-07 11:00:47 -08:00
README.md refactor: switch packages away from deep cross-package imports (#43431) 2021-10-01 18:28:43 +00: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.