What happened?
When depending on an npm package that has an archive with directories that do not contain the searchable permission (e.g.
drw-r--r--), the bazel cache fails to write the action output to the cache getting a permission denied on the files in the extracted non-searchable directory. If you are using remote execution, you may have the build exit due to the executors failing with the same permission denied. This started with the latest feature if extracting tars vis bsdtar. The prior method of extracting packages did not seem to have any issue.
I also think it would be nice if rules_js could gracefully handle this scenario considering npm and pnpm appear to handle extracting the package okay. However, at the end of the day, I don't really know how frequent this is, nor if it's really worth the effort of maintaining on your side. I mostly just wanted to report it for visibility.
Related issue on package where I noticed this: pngjs/pngjs#381
I've also reported this to the remote executions service I am using, as it crashes the remote executor.
Version
Development (host) and target OS/architectures:
Output of bazel --version: 7.1.1
Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: 1.4.0
Language(s) and/or frameworks involved:
How to reproduce
A full reproducible repo can be found here: https://github.com/qtica/bazel-rules-js-cache-error-with-bad-package?tab=readme-ov-file
In short, depend on pngjs, have RBE / remote cache (--disk_cache works too) setup and build your target. The remote cache will provide a warning with permission denied. The remote execution service I use results in a crashed executor with the error permission denied resulting in a failed build.
The full details are in the README.md of the reproducible repo.
Any other information?
My current workaround is to vendor the package and provide overrides in the package.json.
{
// <redacted>
"pnpm": {
"overrides": {
"pngjs": "file:./third_party/npm/pngjs-5.0.0"
}
}
}
What happened?
When depending on an npm package that has an archive with directories that do not contain the searchable permission (e.g.
drw-r--r--), the bazel cache fails to write the action output to the cache getting a permission denied on the files in the extracted non-searchable directory. If you are using remote execution, you may have the build exit due to the executors failing with the same permission denied. This started with the latest feature if extracting tars vis bsdtar. The prior method of extracting packages did not seem to have any issue.I also think it would be nice if rules_js could gracefully handle this scenario considering npm and pnpm appear to handle extracting the package okay. However, at the end of the day, I don't really know how frequent this is, nor if it's really worth the effort of maintaining on your side. I mostly just wanted to report it for visibility.
Related issue on package where I noticed this: pngjs/pngjs#381
I've also reported this to the remote executions service I am using, as it crashes the remote executor.
Version
Development (host) and target OS/architectures:
Output of
bazel --version:7.1.1Version of the Aspect rules, or other relevant rules from your
WORKSPACEorMODULE.bazelfile:1.4.0Language(s) and/or frameworks involved:
How to reproduce
A full reproducible repo can be found here: https://github.com/qtica/bazel-rules-js-cache-error-with-bad-package?tab=readme-ov-file
In short, depend on
pngjs, have RBE / remote cache (--disk_cache works too) setup and build your target. The remote cache will provide a warning with permission denied. The remote execution service I use results in a crashed executor with the error permission denied resulting in a failed build.The full details are in the README.md of the reproducible repo.
Any other information?
My current workaround is to vendor the package and provide overrides in the
package.json.