angular/packages/compiler-cli/private
Paul Gschwendtner fe2a8de1b5 refactor(compiler-cli): expose tooling code through private entry-point (#43431)
Similar to the other private entry-points we have added for localize,
bazel or the migrations, we should expose the tooling code through
a dedicated private export. This will make the compiler-cli exports
more consistent and it will become easier for the CLI to export
necessary code.

PR Close #43431
2021-10-01 18:28:46 +00:00
..
bazel.ts refactor: switch packages away from deep cross-package imports (#43431) 2021-10-01 18:28:43 +00:00
BUILD.bazel refactor(compiler-cli): expose tooling code through private entry-point (#43431) 2021-10-01 18:28:46 +00:00
localize.ts refactor: switch packages away from deep cross-package imports (#43431) 2021-10-01 18:28:43 +00:00
migrations.ts refactor: switch packages away from deep cross-package imports (#43431) 2021-10-01 18:28:43 +00:00
README.md refactor: switch packages away from deep cross-package imports (#43431) 2021-10-01 18:28:43 +00:00
tooling.ts refactor(compiler-cli): expose tooling code through private entry-point (#43431) 2021-10-01 18:28:46 +00: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.