Runs a js_binary as a build action.
This macro wraps Aspect bazel-lib's run_binary (https://github.com/aspect-build/bazel-lib/blob/main/lib/run_binary.bzl) and adds attributes and features specific to rules_js's js_binary.
Load this with,
load("@aspect_rules_js//js:defs.bzl", "js_run_binary")
Macros and Functions
js_run_binary
Wrapper around @aspect_bazel_lib run_binary that adds convienence attributes for using a js_binary tool.
This rule does not require Bash native.genrule
.
Example usage (generated)
load("@aspect_rules_js//js:defs.bzl", "js_run_binary")
js_run_binary(
# Target name
name = "",
# The tool to run in the action
tool = None,
)
name
Target name
tool
The tool to run in the action.
Should be a js_binary rule. Use Aspect bazel-lib's run_binary (https://github.com/aspect-build/bazel-lib/blob/main/lib/run_binary.bzl) for other *_binary rule types.
env
Environment variables of the action.
Subject to $(location)
and make variable expansion.
srcs
Additional inputs of the action.
These labels are available for $(location)
expansion in args
and env
.
outs
Output files generated by the action.
These labels are available for $(location)
expansion in args
and env
.
out_dirs
Output directories generated by the action.
These labels are not available for $(location)
expansion in args
and env
since
they are not pre-declared labels created via attr.output_list(). Output directories are
declared instead by ctx.actions.declare_directory
.
args
Command line arguments of the binary.
Subject to $(location)
and make variable expansion.
chdir
Working directory to run the binary or test in, relative to the workspace.
This overrides the chdir value if set on the js_binary tool target.
By default, Bazel always runs in the workspace root.
To run in the directory containing the js_run_binary under the source tree, use
chdir = package_name()
(or if you're in a macro, use native.package_name()
).
To run in the output directory where the js_run_binary writes outputs, use
chdir = "$(RULEDIR)"
WARNING: this will affect other paths passed to the program, either as arguments or in configuration files, which are workspace-relative.
You may need ../../
segments to re-relativize such paths to the new working directory.
stdout
set to capture the stdout of the binary to a file, which can later be used as an input to another target
subject to the same semantics as outs
stderr
set to capture the stderr of the binary to a file, which can later be used as an input to another target
subject to the same semantics as outs
exit_code_out
set to capture the exit code of the binary to a file, which can later be used as an input to another target
subject to the same semantics as outs
. Note that setting this will force the binary to exit 0.
If the binary creates outputs and these are declared, they must still be created
silent_on_success
produce no output on stdout nor stderr when program exits with status code 0.
This makes node binaries match the expected bazel paradigm.
copy_srcs_to_bin
When True, all srcs files are copied to the output tree that are not already there.
log_level
Set the logging level of the js_binary tool.
This overrides the log level set on the js_binary tool target.
mnemonic
A one-word description of the action, for example, CppCompile or GoLink.
progress_message
Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain %{label}, %{input}, or %{output} patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient.
execution_requirements
Information for scheduling the action.
For example,
execution_requirements = {
"no-cache": "1",
},
See https://docs.bazel.build/versions/main/be/common-definitions.html#common.tags for useful keys.
kwargs
Additional arguments