To increase the ease of development we are moving @angular/docs into the adev directory within this repo. While
we are doing this to improve our development experience in the short term, efforts are also in place
to maintain a division between this @angular/docs (shared) code and adev itself, so that it can be extracted
back out in the future when components is ready to leverage it as well.
PR Close#57132
When we started fixing the version mismatch with local 1st-party
packages, we also re-routed all dependencies like `@lezer/javascript`
into `adev/node_modules`. This works fine, but results in a different
version mismatch because the codemirror dependencies may resolve the
Angular version from `/node_modules`- causing some subtle complex
runtime error.
This commit fixes this by only re-routing dependencies that have
dependency on e.g. `@angular/core` into `adev/node_modules`.
Fixes#55298.
PR Close#55349
There is quite some trickery going on with the adev build related to
local packages:
- Adev builds using npm packages from `/node_modules`
- At runtime, we are adding `HEAD` packages for e.g. `@angular/core` to
the bundles.
- At build time, the CLI, or Angular devkit may accidentally resolve to
`@angular/core` from `/node_modules/`— which is the core version from
npm, transitively installed via `@angular/docs`.
This causes a version mismatch, leading to issues like:
- CLI throwing because of a mismatch. https://github.com/angular/angular/issues/54858#issuecomment-2047188739
- Compiler changes not being picked up. https://github.com/angular/angular/issues/54858#issuecomment-2041322427
This commit attempts to fix this by:
- Linking all Angular `HEAD` packages into `adev/node_modules`. The
current logic attempts to link into `/node_modules`, but this does not
override existing `@angular/core`!
- Linking all direct external NPM packages, like
`@angular_devkit/build-angular` into `adev/node_modules` without their
transitive deps. This allows proper resolution of e.g. compiler as
node looks in `adev/node_modules` first, and falls back for the rest
to the execroot `node_modules`, or symlink target destination (if
`preserveSymlinks=false`).
Note: This is still not 100% ideal because a direct external NPM
dependency may have a transitive dependency that has another transitive
dependency on `@angular/core`. In those cases, the may be a conflict
that is not resolvable until we switch to a Bazel toolchain with better
first party resolution support.
PR Close#55282
