-
Notifications
You must be signed in to change notification settings - Fork 11.9k
feat(@angular/build): allow enabling Bazel sandbox plugin with esbuild #30654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
For additional context: This will also be useful / needed for our usages of CLI inside Bazel for e.g. angular.dev |
d584b32 to
04007f0
Compare
9338465 to
8722ef6
Compare
|
I've had to change the original plugin to try for a |
8722ef6 to
2ebbff4
Compare
|
Should I make any further changes here? Happy to help get this merged if it's something I can support. |
|
@clydin I assume this is something you're still looking at / want to look at? |
b9c4685 to
aa03fc8
Compare
aa03fc8 to
a6c50ca
Compare
|
I've updated the logic once more to allow remapping into the runfiles tree when requested. I've found this to be needed when executing the Architect from a |
a6c50ca to
9e46123
Compare
faed857 to
6c78377
Compare
Setting the new `ENABLE_BAZEL_SANDBOX_PLUGIN` environment variable to `true` or `1` during a build with the `esbuild` based builder will now inject a special plugin to make `esbuild` compatible with Bazel builds in the output tree. When trying to integrate the `esbuild` based builder into Bazel with `rules_js` we found that it will incorrectly follow symlinks out of the sandbox. This is because Node.js based tooling runs in the output tree to support canonical JS project directory structures. The output tree will contain symlinks outside of the sandbox. Node tooling will generally follow these symlinks, which violates the rules of Bazel sandboxing. This can manifest in a wide variety of errors. One example we encountered with Angular compilation is that the symlinked browser entry point (e.g. `main.ts`) is outside of the range of `tsconfig.json` when the compiler follows the symlink. The plugin itself was originally written in https://github.com/aspect-build/rules_esbuild. The version container in this commit is a fork of https://github.com/aspect-build/rules_esbuild/blob/e4e49d3354cbf7087c47ac9c5f2e6fe7f5e398d3/esbuild/private/plugins/bazel-sandbox.js. I've adapted the JS file to TypeScript and made no further changes.
6c78377 to
185e5b7
Compare
|
Is this still need in version 22.2.1 following: 261dbb3? |
|
@alan-agius4 I've found that not to work for me. I tried it instead of my patch and my build went back to failing with path errors. |
|
@clydin can you take a look at the above. |
|
I can confirm, tested post merge 20.2.1. The bug still persists. This is becoming quite problematic. Currently using a scrappy esbuild overwrite package to patch. Would really appreciate a fix for this! |
|
We are using this patch on a medium-large Angular app with |
|
Same for us! Having problems with testing, because we cannot patch the underlying bazel sandbox escape. Would be really nice to have an official fix and switch back to the official build tools. |
PR Checklist
Please check to confirm your PR fulfills the following requirements:
Docs have been added / updated (for bug fixes / features)User facing documentation is intentionally omitted as this will be considered internal for now.
PR Type
What kind of change does this PR introduce?
What is the current behavior?
When trying to integrate the
esbuildbased builder into Bazel withrules_jswe found that it will incorrectly follow symlinks out of the sandbox. This is because Node.js based tooling runs in the output tree to support canonical JS project directory structures. The output tree will contain symlinks outside of the sandbox. Node tooling will generally follow these symlinks, which violates the rules of Bazel sandboxing. This can manifest in a wide variety of errors. One example we encountered with Angular compilation is that the symlinked browser entry point (e.g.main.ts) is outside of the range oftsconfig.jsonwhen the compiler follows the symlink.Issue Number: N/A
What is the new behavior?
Setting the new
ENABLE_BAZEL_SANDBOX_PLUGINenvironment variable totrueor1during a build with theesbuildbased builder will now inject a special plugin to makeesbuildcompatible with Bazel builds in the output tree.Does this PR introduce a breaking change?
Other information
The plugin itself was originally written in https://github.com/aspect-build/rules_esbuild. The version container in this commit is a fork of https://github.com/aspect-build/rules_esbuild/blob/e4e49d3354cbf7087c47ac9c5f2e6fe7f5e398d3/esbuild/private/plugins/bazel-sandbox.js. I've adapted the JS file to TypeScript and made no further changes.