mirror of
https://github.com/angular/angular-cli.git
synced 2025-05-15 10:11:50 +08:00
cdf5d86688
Currently the interop resulting target of a `ts_project` ends up not necessarily working at runtime. This may be the case because a consuming Node program may end up with mixes of `node_modules` dependencies from `rules_nodejs` (old) and `rules_js` (new). This sounds fine at first glance, but in practice can break very subtly because: * Rules NodeJS leverages the linker, creating `node_module` directories outside of Bazel, at runtime. These don't depend on symlink resolving. * Rules JS puts real node module folders via Bazel actions. These rely on `pnpm` non-hoisting layout, and symlink resolving. As we can see there is a hard conflict with symlinks. They need to be enabled with the new toolchain, but the other one doesn't enable symlink resolution, and enabling is not possible as we'd otherwise risk escaping the sandbox and cause even more subtle errors. A good compromise solution is to automatically drop the `rules_js` node module files/folder in the interop-`rules_nodejs` target and instead brining in the equivalent `@npm//` dependencies from `rules_nodejs`. This kind of keeps the logic similar to when not using `rules_js` or the interop, and enables the simplest & safest mental model; and it works compared to other solutions I tried with symlinking. Notably, we can't keep both node module variants as the linker doesn't override existing node module files from e.g. rules_js then (and would break then).
10 lines
233 B
TypeScript
10 lines
233 B
TypeScript
/**
|
|
* @license
|
|
* Copyright Google LLC All Rights Reserved.
|
|
*
|
|
* Use of this source code is governed by an MIT-style license that can be
|
|
* found in the LICENSE file at https://angular.dev/license
|
|
*/
|
|
|
|
export * from './src/index';
|