mirror of
https://github.com/angular/angular
synced 2026-05-24 09:28:37 +00:00
a02e270fcb
Previously we never could use relative imports to import e.g. `Component` in e.g. the `core/tests/bundling` folder. This was necessary because otherwise the Angular compiler wouldn't process those files as it wouldn't recognize the Angular decorator as the one from `@angular/core`. Notably this still isn't a large issue because relative imports still work for most core tests, that are JIT compiled! For bundling tests though, or some smaller targets, our new upcoming guidelines for using relative imports inside the full package; fall apart. This commit unblocks this effort and allows us to use relative imports in all tests of `packages/core`. This is achieved by leveraging the existing `isCore` functionality of the compiler, and fixing a few instances that were missing before. PR Close #60268 |
||
|---|---|---|
| .. | ||
| babel.d.ts | ||
| bazel.ts | ||
| BUILD.bazel | ||
| localize.ts | ||
| migrations.ts | ||
| README.md | ||
| tooling.ts | ||
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.