title: Built-ins layout: default toc: true nav: rule

Built-in rules

These rules are available without any npm installation, via the WORKSPACE install of the build_bazel_rules_nodejs workspace. This is necessary to bootstrap Bazel to run the package manager to download other rules from NPM.

node_repositories

USAGE

To be run in user's WORKSPACE to install rules_nodejs dependencies.

This rule sets up node, npm, and yarn. The versions of these tools can be specified in one of three ways

Simplest Usage

Specify no explicit versions. This will download and use the latest NodeJS & Yarn that were available when the version of rules_nodejs you‘re using was released. Note that you can skip calling node_repositories in your WORKSPACE file - if you later try to yarn_install or npm_install, we’ll automatically select this simple usage for you.

Forced version(s)

You can select the version of NodeJS and/or Yarn to download & use by specifying it when you call node_repositories, using a value that matches a known version (see the default values)

Using a custom version

You can pass in a custom list of NodeJS and/or Yarn repositories and URLs for node_resositories to use.

Custom NodeJS versions

To specify custom NodeJS versions, use the node_repositories attribute

node_repositories(
    node_repositories = {
        "10.10.0-darwin_amd64": ("node-v10.10.0-darwin-x64.tar.gz", "node-v10.10.0-darwin-x64", "00b7a8426e076e9bf9d12ba2d571312e833fe962c70afafd10ad3682fdeeaa5e"),
        "10.10.0-linux_amd64": ("node-v10.10.0-linux-x64.tar.xz", "node-v10.10.0-linux-x64", "686d2c7b7698097e67bcd68edc3d6b5d28d81f62436c7cf9e7779d134ec262a9"),
        "10.10.0-windows_amd64": ("node-v10.10.0-win-x64.zip", "node-v10.10.0-win-x64", "70c46e6451798be9d052b700ce5dadccb75cf917f6bf0d6ed54344c856830cfb"),
    },
)

These can be mapped to a custom download URL, using node_urls

node_repositories(
    node_version = "10.10.0",
    node_repositories = {"10.10.0-darwin_amd64": ("node-v10.10.0-darwin-x64.tar.gz", "node-v10.10.0-darwin-x64", "00b7a8426e076e9bf9d12ba2d571312e833fe962c70afafd10ad3682fdeeaa5e")},
    node_urls = ["https://mycorpproxy/mirror/node/v{version}/{filename}"],
)

A Mac client will try to download node from https://mycorpproxy/mirror/node/v10.10.0/node-v10.10.0-darwin-x64.tar.gz and expect that file to have sha256sum 00b7a8426e076e9bf9d12ba2d571312e833fe962c70afafd10ad3682fdeeaa5e

Custom Yarn versions

To specify custom Yarn versions, use the yarn_repositories attribute

node_repositories(
    yarn_repositories = {
        "1.12.1": ("yarn-v1.12.1.tar.gz", "yarn-v1.12.1", "09bea8f4ec41e9079fa03093d3b2db7ac5c5331852236d63815f8df42b3ba88d"),
    },
)

Like node_urls, the yarn_urls attribute can be used to provide a list of custom URLs to use to download yarn

node_repositories(
    yarn_repositories = {
        "1.12.1": ("yarn-v1.12.1.tar.gz", "yarn-v1.12.1", "09bea8f4ec41e9079fa03093d3b2db7ac5c5331852236d63815f8df42b3ba88d"),
    },
    yarn_version = "1.12.1",
    yarn_urls = [
        "https://github.com/yarnpkg/yarn/releases/download/v{version}/{filename}",
    ],
)

Will download yarn from https://github.com/yarnpkg/yarn/releases/download/v1.2.1/yarn-v1.12.1.tar.gz and expect the file to have sha256sum 09bea8f4ec41e9079fa03093d3b2db7ac5c5331852236d63815f8df42b3ba88d.

Using a local version

To avoid downloads, you can check in vendored copies of NodeJS and/or Yarn and set vendored_node and or vendored_yarn to point to those before calling node_repositories. You can also point to a location where node is installed on your computer, but we don't recommend this because it leads to version skew between you, your coworkers, and your Continuous Integration environment. It also ties your build to a single platform, preventing you from cross-compiling into a Linux docker image on Mac for example.

See the the repositories documentation for how to use the resulting repositories.

Manual install

You can optionally pass a package_json array to node_repositories. This lets you use Bazel‘s version of yarn or npm, yet always run the package manager yourself. This is an advanced scenario you can use in place of the npm_install or yarn_install rules, but we don’t recommend it, and might remove it in the future.

load("@build_bazel_rules_nodejs//:index.bzl", "node_repositories")
node_repositories(package_json = ["//:package.json", "//subpkg:package.json"])

Running bazel run @nodejs//:yarn_node_repositories in this repo would create /node_modules and /subpkg/node_modules.

Note that the dependency installation scripts will run in each subpackage indicated by the package_json attribute.

ATTRIBUTES

(Name, mandatory): A unique name for this repository.

(Dictionary: String -> String): auth to use for all url requests Example: {“type”: “basic”, “login”: “”, “password”: “” }

Defaults to {}

(Dictionary: String -> List of strings): Custom list of node repositories to use

A dictionary mapping NodeJS versions to sets of hosts and their corresponding (filename, strip_prefix, sha256) tuples. You should list a node binary for every platform users have, likely Mac, Windows, and Linux.

By default, if this attribute has no items, we'll use a list of all public NodeJS releases.

Defaults to {}

(List of strings): custom list of URLs to use to download NodeJS

Each entry is a template for downloading a node distribution.

The {version} parameter is substituted with the node_version attribute, and {filename} with the matching entry from the node_repositories attribute.

Defaults to ["https://mirror.bazel.build/nodejs.org/dist/v{version}/{filename}", "https://nodejs.org/dist/v{version}/{filename}"]

(String): the specific version of NodeJS to install or, if vendored_node is specified, the vendored version of node

Defaults to "12.13.0"

(List of labels): (ADVANCED, not recommended) a list of labels, which indicate the package.json files that will be installed when you manually run the package manager, e.g. with bazel run @nodejs//:yarn_node_repositories or bazel run @nodejs//:npm_node_repositories install. If you use bazel-managed dependencies, you should omit this attribute.

Defaults to []

(Boolean): Turn on --node_options=--preserve-symlinks for nodejs_binary and nodejs_test rules.

When this option is turned on, node will preserve the symlinked path for resolves instead of the default behavior of resolving to the real path. This means that all required files must be in be included in your runfiles as it prevents the default behavior of potentially resolving outside of the runfiles. For example, all required files need to be included in your node_modules filegroup. This option is desirable as it gives a stronger guarantee of hermeticity which is required for remote execution.

Defaults to True

(Dictionary: String -> String, mandatory): A dictionary from local repository name to global repository name. This allows controls over workspace dependency resolution for dependencies of this repository.For example, an entry "@foo": "@bar" declares that, for any time this repository depends on @foo (such as a dependency on @foo//some:target, it should actually resolve that dependency within globally-declared @bar (@bar//some:target).

(Label): the local path to a pre-installed NodeJS runtime.

If set then also set node_version to the version that of node that is vendored.

Defaults to None

(Label): the local path to a pre-installed yarn tool

Defaults to None

(Dictionary: String -> String): auth to use for all url requests Example: {“type”: “basic”, “login”: “”, “password”: “” }

Defaults to {}

(Dictionary: String -> List of strings): Custom list of yarn repositories to use.

Dictionary mapping Yarn versions to their corresponding (filename, strip_prefix, sha256) tuples.

By default, if this attribute has no items, we'll use a list of all public NodeJS releases.

Defaults to {}

(List of strings): custom list of URLs to use to download Yarn

Each entry is a template, similar to the node_urls attribute, using yarn_version and yarn_repositories in the substitutions.

Defaults to ["https://mirror.bazel.build/github.com/yarnpkg/yarn/releases/download/v{version}/{filename}", "https://github.com/yarnpkg/yarn/releases/download/v{version}/{filename}"]

(String): the specific version of Yarn to install

Defaults to "1.19.1"

nodejs_binary

USAGE

Runs some JavaScript code in NodeJS.

ATTRIBUTES

(Name, mandatory): A unique name for this target.

(List of strings): Pass these configuration environment variables to the resulting binary. Chooses a subset of the configuration environment variables (taken from ctx.var), which also includes anything specified via the --define flag. Note, this can lead to different outputs produced by this rule.

Defaults to []

(List of labels): Runtime dependencies which may be loaded during execution.

Defaults to []

(List of strings): Default environment variables that are added to configuration_env_vars.

This is separate from the default of configuration_env_vars so that a user can set configuration_env_vars without losing the defaults that should be set in most cases.

The set of default environment variables is:

VERBOSE_LOGS: use by some rules & tools to turn on debug output in their logs
NODE_DEBUG: used by node.js itself to print more logs
RUNFILES_LIB_DEBUG: print diagnostic message from Bazel runfiles.bash helper

Defaults to ["VERBOSE_LOGS", "NODE_DEBUG", "RUNFILES_LIB_DEBUG"]

(Label, mandatory): The script which should be executed first, usually containing a main function.

If the entry JavaScript file belongs to the same package (as the BUILD file), you can simply reference it by its relative name to the package directory:

nodejs_binary(
    name = "my_binary",
    ...
    entry_point = ":file.js",
)

You can specify the entry point as a typescript file so long as you also include the ts_library target in data:

ts_library(
    name = "main",
    srcs = ["main.ts"],
)

nodejs_binary(
    name = "bin",
    data = [":main"]
    entry_point = ":main.ts",
)

The rule will use the corresponding .js output of the ts_library rule as the entry point.

If the entry point target is a rule, it should produce a single JavaScript entry file that will be passed to the nodejs_binary rule. For example:

filegroup(
    name = "entry_file",
    srcs = ["main.js"],
)

nodejs_binary(
    name = "my_binary",
    entry_point = ":entry_file",
)

The entry_point can also be a label in another workspace:

nodejs_binary(
    name = "history-server",
    entry_point = "@npm//:node_modules/history-server/modules/cli.js",
    data = ["@npm//history-server"],
)

(Boolean): Link the workspace root to the bin_dir to support absolute requires like ‘my_wksp/path/to/file’. If source files need to be required then they can be copied to the bin_dir with copy_to_bin.

Defaults to False

(Label): The npm packages which should be available to require() during execution.

This attribute is DEPRECATED. As of version 0.13.0 the recommended approach to npm dependencies is to use fine grained npm dependencies which are setup with the yarn_install or npm_install rules. For example, in targets that used a //:node_modules filegroup,

nodejs_binary(
    name = "my_binary",
    ...
    node_modules = "//:node_modules",
)

which specifies all files within the //:node_modules filegroup to be inputs to the my_binary. Using fine grained npm dependencies, my_binary is defined with only the npm dependencies that are needed:

nodejs_binary(
    name = "my_binary",
    ...
    data = [
        "@npm//foo",
        "@npm//bar",
        ...
    ],
)

In this case, only the foo and bar npm packages and their transitive deps are includes as inputs to the my_binary target which reduces the time required to setup the runfiles for this target (see https://github.com/bazelbuild/bazel/issues/5153).

The @npm external repository and the fine grained npm package targets are setup using the yarn_install or npm_install rule in your WORKSPACE file:

yarn_install( name = “npm”, package_json = “//:package.json”, yarn_lock = “//:yarn.lock”, )

For other rules such as jasmine_node_test, fine grained npm dependencies are specified in the deps attribute:

jasmine_node_test(
    name = "my_test",
    ...
    deps = [
        "@npm//jasmine",
        "@npm//foo",
        "@npm//bar",
        ...
    ],
)

Defaults to //:node_modules_none

(List of strings): Arguments which are passed to every execution of the program. To pass a node startup option, prepend it with --node_options=, e.g. --node_options=--preserve-symlinks.

Subject to ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.

Subject to predefined source/output path variables substitutions.

The predefined variables execpath, execpaths, rootpath, rootpaths, location, and locations take label parameters (e.g. $(execpath //foo:bar)) and substitute the file paths denoted by that label.

See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_label_variables for more info.

NB: This $(location) substition returns the manifest file path which differs from the *_binary & *_test args and genrule bazel substitions. This will be fixed in a future major release. See docs string of expand_location_into_runfiles macro in internal/common/expand_into_runfiles.bzl for more info.

The recommended approach is to now use $(rootpath) where you previously used $(location).

To get from a $(rootpath) to the absolute path that $$(rlocation $(location)) returned you can either use $$(rlocation $(rootpath)) if you are in the templated_args of a nodejs_binary or nodejs_test:

BUILD.bazel:

nodejs_test(
    name = "my_test",
    data = [":bootstrap.js"],
    templated_args = ["--node_options=--require=$$(rlocation $(rootpath :bootstrap.js))"],
)

or if you're in the context of a .js script you can pass the $(rootpath) as an argument to the script and use the javascript runfiles helper to resolve to the absolute path:

BUILD.bazel:

nodejs_test(
    name = "my_test",
    data = [":some_file"],
    entry_point = ":my_test.js",
    templated_args = ["$(rootpath :some_file)"],
)

my_test.js

const runfiles = require(process.env['BAZEL_NODE_RUNFILES_HELPER']);
const args = process.argv.slice(2);
const some_file = runfiles.resolveWorkspaceRelative(args[0]);

NB: Bazel will error if it sees the single dollar sign $(rlocation path) in templated_args as it will try to expand $(rlocation) since we now expand predefined & custom “make” variables such as $(COMPILATION_MODE), $(BINDIR) & $(TARGET_CPU) using ctx.expand_make_variables. See https://docs.bazel.build/versions/master/be/make-variables.html.

To prevent expansion of $(rlocation) write it as $$(rlocation). Bazel understands $$ to be the string literal $ and the expansion results in $(rlocation) being passed as an arg instead of being expanded. $(rlocation) is then evaluated by the bash node launcher script and it calls the rlocation function in the runfiles.bash helper. For example, the templated arg $$(rlocation $(rootpath //:some_file)) is expanded by Bazel to $(rlocation ./some_file) which is then converted in bash to the absolute path of //:some_file in runfiles by the runfiles.bash helper before being passed as an argument to the program.

NB: nodejs_binary and nodejs_test will preserve the legacy behavior of $(rlocation) so users don't need to update to $$(rlocation). This may be changed in the future.

Subject to predefined variables & custom variable substitutions.

Predefined “Make” variables such as $(COMPILATION_MODE) and $(TARGET_CPU) are expanded. See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_variables.

Custom variables are also expanded including variables set through the Bazel CLI with --define=SOME_VAR=SOME_VALUE. See https://docs.bazel.build/versions/master/be/make-variables.html#custom_variables.

Predefined genrule variables are not supported in this context.

Defaults to []

nodejs_test

USAGE

Identical to nodejs_binary, except this can be used with bazel test as well. When the binary returns zero exit code, the test passes; otherwise it fails.

nodejs_test is a convenient way to write a novel kind of test based on running your own test runner. For example, the ts-api-guardian library has a way to assert the public API of a TypeScript program, and uses nodejs_test here: https://github.com/angular/angular/blob/master/tools/ts-api-guardian/index.bzl

If you just want to run a standard test using a test runner from npm, use the generated *_test target created by npm_install/yarn_install, such as mocha_test. Some test runners like Karma and Jasmine have custom rules with added features, e.g. jasmine_node_test.

Bazel always runs tests with a working directory set to your workspace root. If your test needs to run in a different directory, you can write a process.chdir helper script and invoke it before the test with a --require argument, like templated_args = ["--node_options=--require=./$(rootpath chdir.js)"]. See rules_nodejs/internal/node/test/chdir for an example.

To debug a Node.js test, we recommend saving a group of flags together in a “config”. Put this in your tools/bazel.rc so it's shared with your team:

# Enable debugging tests with --config=debug
test:debug --test_arg=--node_options=--inspect-brk --test_output=streamed --test_strategy=exclusive --test_timeout=9999 --nocache_test_results

Now you can add --config=debug to any bazel test command line. The runtime will pause before executing the program, allowing you to connect a remote debugger.

ATTRIBUTES

(Name, mandatory): A unique name for this target.

Defaults to []

(List of labels): Runtime dependencies which may be loaded during execution.

Defaults to []

(List of strings): Default environment variables that are added to configuration_env_vars.

This is separate from the default of configuration_env_vars so that a user can set configuration_env_vars without losing the defaults that should be set in most cases.

The set of default environment variables is:

VERBOSE_LOGS: use by some rules & tools to turn on debug output in their logs
NODE_DEBUG: used by node.js itself to print more logs
RUNFILES_LIB_DEBUG: print diagnostic message from Bazel runfiles.bash helper

Defaults to ["VERBOSE_LOGS", "NODE_DEBUG", "RUNFILES_LIB_DEBUG"]

(Label, mandatory): The script which should be executed first, usually containing a main function.

If the entry JavaScript file belongs to the same package (as the BUILD file), you can simply reference it by its relative name to the package directory:

nodejs_binary(
    name = "my_binary",
    ...
    entry_point = ":file.js",
)

You can specify the entry point as a typescript file so long as you also include the ts_library target in data:

ts_library(
    name = "main",
    srcs = ["main.ts"],
)

nodejs_binary(
    name = "bin",
    data = [":main"]
    entry_point = ":main.ts",
)

The rule will use the corresponding .js output of the ts_library rule as the entry point.

If the entry point target is a rule, it should produce a single JavaScript entry file that will be passed to the nodejs_binary rule. For example:

filegroup(
    name = "entry_file",
    srcs = ["main.js"],
)

nodejs_binary(
    name = "my_binary",
    entry_point = ":entry_file",
)

The entry_point can also be a label in another workspace:

nodejs_binary(
    name = "history-server",
    entry_point = "@npm//:node_modules/history-server/modules/cli.js",
    data = ["@npm//history-server"],
)

(Integer): The expected exit code for the test. Defaults to 0.

Defaults to 0

Defaults to False

(Label): The npm packages which should be available to require() during execution.

nodejs_binary(
    name = "my_binary",
    ...
    node_modules = "//:node_modules",
)

nodejs_binary(
    name = "my_binary",
    ...
    data = [
        "@npm//foo",
        "@npm//bar",
        ...
    ],
)

The @npm external repository and the fine grained npm package targets are setup using the yarn_install or npm_install rule in your WORKSPACE file:

yarn_install( name = “npm”, package_json = “//:package.json”, yarn_lock = “//:yarn.lock”, )

For other rules such as jasmine_node_test, fine grained npm dependencies are specified in the deps attribute:

jasmine_node_test(
    name = "my_test",
    ...
    deps = [
        "@npm//jasmine",
        "@npm//foo",
        "@npm//bar",
        ...
    ],
)

Defaults to //:node_modules_none

(List of strings): Arguments which are passed to every execution of the program. To pass a node startup option, prepend it with --node_options=, e.g. --node_options=--preserve-symlinks.

Subject to ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.

Subject to predefined source/output path variables substitutions.

See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_label_variables for more info.

The recommended approach is to now use $(rootpath) where you previously used $(location).

BUILD.bazel:

nodejs_test(
    name = "my_test",
    data = [":bootstrap.js"],
    templated_args = ["--node_options=--require=$$(rlocation $(rootpath :bootstrap.js))"],
)

or if you're in the context of a .js script you can pass the $(rootpath) as an argument to the script and use the javascript runfiles helper to resolve to the absolute path:

BUILD.bazel:

nodejs_test(
    name = "my_test",
    data = [":some_file"],
    entry_point = ":my_test.js",
    templated_args = ["$(rootpath :some_file)"],
)

my_test.js

const runfiles = require(process.env['BAZEL_NODE_RUNFILES_HELPER']);
const args = process.argv.slice(2);
const some_file = runfiles.resolveWorkspaceRelative(args[0]);

NB: nodejs_binary and nodejs_test will preserve the legacy behavior of $(rlocation) so users don't need to update to $$(rlocation). This may be changed in the future.

Subject to predefined variables & custom variable substitutions.

Predefined “Make” variables such as $(COMPILATION_MODE) and $(TARGET_CPU) are expanded. See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_variables.

Predefined genrule variables are not supported in this context.

Defaults to []

npm_install

USAGE

Runs npm install during workspace setup.

This rule will set the environment variable BAZEL_NPM_INSTALL to ‘1’ (unless it set to another value in the environment attribute). Scripts may use to this to check if yarn is being run by the npm_install repository rule.

ATTRIBUTES

(Name, mandatory): A unique name for this repository.

(List of strings): Arguments passed to npm install.

See npm CLI docs https://docs.npmjs.com/cli/install.html for complete list of supported arguments.

Defaults to []

(List of labels): Data files required by this rule.

If symlink_node_modules is True, this attribute is optional since the package manager will run in your workspace folder. It is recommended, however, that all files that the package manager depends on, such as .rc files or files used in postinstall, are added symlink_node_modules is True so that the repository rule is rerun when any of these files change.

If symlink_node_modules is False, the package manager is run in the bazel external repository so all files that the package manager depends on must be listed.

Defaults to []

(Dictionary: String -> String): Environment variables to set before calling the package manager.

Defaults to {}

(List of strings): List of file extensions to be included in the npm package targets.

For example, [“.js”, “.d.ts”, “.proto”, “.json”, ""].

This option is useful to limit the number of files that are inputs to actions that depend on npm package targets. See https://github.com/bazelbuild/bazel/issues/5153.

If set to an empty list then all files are included in the package targets. If set to a list of extensions, only files with matching extensions are included in the package targets. An empty string in the list is a special string that denotes that files with no extensions such as README should be included in the package targets.

This attribute applies to both the coarse @wksp//:node_modules target as well as the fine grained targets such as @wksp//foo.

Defaults to []

(String): Experimental attribute that can be used to override the generated BUILD.bazel file and set its contents manually.

Can be used to work-around a bazel performance issue if the default @wksp//:node_modules target has too many files in it. See https://github.com/bazelbuild/bazel/issues/5153. If you are running into performance issues due to a large node_modules target it is recommended to switch to using fine grained npm dependencies.

Defaults to ""

(Label, mandatory)

(Boolean): If stdout and stderr should be printed to the terminal.

Defaults to True

(Boolean): Turn on stricter visibility for generated BUILD.bazel files

When enabled, only dependencies within the given package.json file are given public visibility. All transitive dependencies are given limited visibility, enforcing that all direct dependencies are listed in the package.json file.

Currently the default is set False, but will likely be flipped True in rules_nodejs 3.0.0

Defaults to False

(Boolean): Turn symlinking of node_modules on

This requires the use of Bazel 0.26.0 and the experimental managed_directories feature.

When true, the package manager will run in the package.json folder and the resulting node_modules folder will be symlinked into the external repository create by this rule.

When false, the package manager will run in the external repository created by this rule and any files other than the package.json file and the lock file that are required for it to run should be listed in the data attribute.

Defaults to True

(Integer): Maximum duration of the package manager execution in seconds.

Defaults to 3600

pkg_npm

USAGE

The pkg_npm rule creates a directory containing a publishable npm artifact.

Example:

load("@build_bazel_rules_nodejs//:index.bzl", "pkg_npm")

pkg_npm(
    name = "my_package",
    srcs = ["package.json"],
    deps = [":my_typescript_lib"],
    substitutions = {"//internal/": "//"},
)

You can use a pair of // BEGIN-INTERNAL ... // END-INTERNAL comments to mark regions of files that should be elided during publishing. For example:

function doThing() {
    // BEGIN-INTERNAL
    // This is a secret internal-only comment
    doInternalOnlyThing();
    // END-INTERNAL
}

With the Bazel stamping feature, pkg_npm will replace any placeholder version in your package with the actual version control tag. See the stamping documentation

Usage:

pkg_npm yields three labels. Build the package directory using the default label:

$ bazel build :my_package
Target //:my_package up-to-date:
  bazel-out/fastbuild/bin/my_package
$ ls -R bazel-out/fastbuild/bin/my_package

Dry-run of publishing to npm, calling npm pack (it builds the package first if needed):

$ bazel run :my_package.pack
INFO: Running command line: bazel-out/fastbuild/bin/my_package.pack
my-package-name-1.2.3.tgz
$ tar -tzf my-package-name-1.2.3.tgz

Actually publish the package with npm publish (also builds first):

# Check login credentials
$ bazel run @nodejs//:npm_node_repositories who
# Publishes the package
$ bazel run :my_package.publish

You can pass arguments to npm by escaping them from Bazel using a double-hyphen, for example:

bazel run my_package.publish -- --tag=next

ATTRIBUTES

(Name, mandatory): A unique name for this target.

(List of labels): Other targets which produce files that should be included in the package, such as rollup_bundle

Defaults to []

(List of labels): Other pkg_npm rules whose content is copied into this package.

Defaults to []

(Label): Provides info about the build context, such as stamping.

By default it reads from the bazel command line, such as the --stamp argument. Use this to override values for this target, such as enabling or disabling stamping. You can use the node_context_data rule in @build_bazel_rules_nodejs//internal/node:context.bzl to create a NodeContextInfo. The dependencies of this attribute must provide: NodeContextInfo

Defaults to @build_bazel_rules_nodejs//internal:node_context_data

(String): Optional package_name that this npm package may be imported as.

Defaults to ""

(String): DEPRECATED: use substitutions instead.

replace_with_version = "my_version_placeholder" is just syntax sugar for substitutions = {"my_version_placeholder": "{BUILD_SCM_VERSION}"}.

Follow this deprecation at https://github.com/bazelbuild/rules_nodejs/issues/2158

Defaults to "0.0.0-PLACEHOLDER"

(List of labels): Files inside this directory which are simply copied into the package.

Defaults to []

(Dictionary: String -> String): Key-value pairs which are replaced in all the files while building the package.

You can use values from the workspace status command using curly braces, for example {"0.0.0-PLACEHOLDER": "{STABLE_GIT_VERSION}"}.

See the section on stamping in the README

Defaults to {}

(List of strings): External workspaces whose contents should be vendored into this workspace. Avoids external/foo path segments in the resulting package.

Defaults to []

pkg_web

USAGE

Assembles a web application from source files.

ATTRIBUTES

(Name, mandatory): A unique name for this target.

(List of strings): Path prefixes to strip off all srcs, in addition to the current package. Longest wins.

Defaults to []

(Label): Provides info about the build context, such as stamping.

Defaults to @build_bazel_rules_nodejs//internal:node_context_data

(List of labels): Files which should be copied into the package

Defaults to []

(Dictionary: String -> String): Key-value pairs which are replaced in all the files while building the package.

You can use values from the workspace status command using curly braces, for example {"0.0.0-PLACEHOLDER": "{STABLE_GIT_VERSION}"}. See the section on stamping in the README.

Defaults to {}

yarn_install

USAGE

Runs yarn install during workspace setup.

This rule will set the environment variable BAZEL_YARN_INSTALL to ‘1’ (unless it set to another value in the environment attribute). Scripts may use to this to check if yarn is being run by the yarn_install repository rule.

ATTRIBUTES

(Name, mandatory): A unique name for this repository.

(List of strings): Arguments passed to yarn install.

See yarn CLI docs https://yarnpkg.com/en/docs/cli/install for complete list of supported arguments.

Defaults to []

(List of labels): Data files required by this rule.

If symlink_node_modules is False, the package manager is run in the bazel external repository so all files that the package manager depends on must be listed.

Defaults to []

(Dictionary: String -> String): Environment variables to set before calling the package manager.

Defaults to {}

(List of strings): List of file extensions to be included in the npm package targets.

For example, [“.js”, “.d.ts”, “.proto”, “.json”, ""].

This option is useful to limit the number of files that are inputs to actions that depend on npm package targets. See https://github.com/bazelbuild/bazel/issues/5153.

This attribute applies to both the coarse @wksp//:node_modules target as well as the fine grained targets such as @wksp//foo.

Defaults to []

(String): Experimental attribute that can be used to override the generated BUILD.bazel file and set its contents manually.

Defaults to ""

(Label, mandatory)

(Boolean): If stdout and stderr should be printed to the terminal.

Defaults to True

(Boolean): Turn on stricter visibility for generated BUILD.bazel files

Currently the default is set False, but will likely be flipped True in rules_nodejs 3.0.0

Defaults to False

(Boolean): Turn symlinking of node_modules on

This requires the use of Bazel 0.26.0 and the experimental managed_directories feature.

When true, the package manager will run in the package.json folder and the resulting node_modules folder will be symlinked into the external repository create by this rule.

Defaults to True

(Integer): Maximum duration of the package manager execution in seconds.

Defaults to 3600

(Boolean): Use the global yarn cache on the system.

The cache lets you avoid downloading packages multiple times. However, it can introduce non-hermeticity, and the yarn cache can have bugs.

Disabling this attribute causes every run of yarn to have a unique cache_directory.

If True, this rule will pass --mutex network to yarn to ensure that the global cache can be shared by parallelized yarn_install rules.

If False, this rule will pass --cache-folder /path/to/external/repository/__yarn_cache to yarn so that the local cache is contained within the external repository.

Defaults to True

(Label, mandatory)

check_bazel_version

USAGE

Verify the users Bazel version is at least the given one.

This can be used in rule implementations that depend on changes in Bazel, to warn users about a mismatch between the rule and their installed Bazel version.

This should not be used in users WORKSPACE files. To locally pin your Bazel version, just create the .bazelversion file in your workspace.

PARAMETERS

a string indicating the minimum version

optional string to print to your users, could be used to help them update

Defaults to ""

copy_to_bin

USAGE

Copies a source file to bazel-bin at the same workspace-relative path.

e.g. <workspace_root>/foo/bar/a.txt -> <bazel-bin>/foo/bar/a.txt

This is useful to populate the output folder with all files needed at runtime, even those which aren't outputs of a Bazel rule.

This way you can run a binary in the output folder (execroot or runfiles_root) without that program needing to rely on a runfiles helper library or be aware that files are divided between the source tree and the output tree.

PARAMETERS

Name of the rule.

A List of Labels. File(s) to to copy.

further keyword arguments, e.g. visibility

generated_file_test

USAGE

Tests that a file generated by Bazel has identical content to a file in the workspace.

This is useful for testing, where a “snapshot” or “golden” file is checked in, so that you can code review changes to the generated output.

PARAMETERS

Name of the rule.

a Label of the output file generated by another rule

Label of the source file in the workspace

When true, creates a test that will fail only if the golden file is not found anywhere within the generated file. Note that the .update rule is not generated in substring mode.

Defaults to False

if the build uses --compilation_mode dbg then some rules will produce different output. In this case you can specify what the dbg version of the output should look like

Defaults to None

extra arguments passed to the underlying nodejs_test or nodejs_binary

js_library

USAGE

Groups JavaScript code so that it can be depended on like an npm package.

js_library is intended to be used internally within Bazel, such as between two libraries in your monorepo. This rule doesn't perform any build steps (“actions”) so it is similar to a filegroup. However it provides several Bazel “Providers” for interop with other rules.

Compare this to pkg_npm which just produces a directory output, and therefore can't expose individual files to downstream targets and causes a cascading re-build of all transitive dependencies when any file changes. Also pkg_npm is intended to publish your code for external usage outside of Bazel, like by publishing to npm or artifactory, while js_library is for internal dependencies within your repo.

js_library also copies any source files into the bazel-out folder. This is the same behavior as the copy_to_bin rule. By copying the complete package to the output tree, we ensure that the linker (our npm link equivalent) will make your source files available in the node_modules tree where resolvers expect them. It also means you can have relative imports between the files rather than being forced to use Bazel's “Runfiles” semantics where any program might need a helper library to resolve files between the logical union of the source tree and the output tree.

Example

A typical example usage of js_library is to expose some sources with a package name:

ts_project(
    name = "compile_ts",
    srcs = glob(["*.ts"]),
)

js_library(
    name = "my_pkg",
    # Code that depends on this target can import from "@myco/mypkg"
    package_name = "@myco/mypkg",
    # Consumers might need fields like "main" or "typings"
    srcs = ["package.json"],
    # The .js and .d.ts outputs from above will be part of the package
    deps = [":compile_ts"],
)

To help work with “named AMD” modules as required by ts_devserver and other Google-style “concatjs” rules, js_library has some undocumented advanced features you can find in the source code or in our examples. These should not be considered a public API and aren't subject to our usual support and semver guarantees.

Outputs

Like all Bazel rules it produces a default output by providing DefaultInfo. You'll get these outputs if you include this in the srcs of a typical rule like filegroup, and these will be the printed result when you bazel build //some:js_library_target. The default outputs are all of:

DefaultInfo produced by targets in deps
A copy of all sources (InputArtifacts from your source tree) in the bazel-out directory

When there are TypeScript typings files, js_library provides DeclarationInfo so this target can be a dependency of a TypeScript rule. This includes any .d.ts files in srcs as well as transitive ones from deps. It will also provide OutputGroupInfo with a “types” field, so you can select the typings outputs with bazel build //some:js_library_target --output_groups=types or with a filegroup rule using the output_group attribute.

In order to work with the linker (similar to npm link for first-party monorepo deps), js_library provides LinkablePackageInfo for use with our “linker” that makes this package importable.

It also provides:

NpmPackageInfo to interop with rules that expect third-party npm packages.
JsModuleInfo so rules like bundlers can collect the transitive set of .js files
JsNamedModuleInfo for rules that expect named AMD or goog.module format JS

PARAMETERS

a name for the target

the list of files that comprise the package

Defaults to []

the name it will be imported by. Should match the “name” field in the package.json file.

Defaults to None

other targets that provide JavaScript code

Defaults to []

used for undocumented legacy features

npm_package_bin

USAGE

Run an arbitrary npm package binary (e.g. a program under node_modules/.bin/*) under Bazel.

It must produce outputs. If you just want to run a program with bazel run, use the nodejs_binary rule.

This is like a genrule() except that it runs our launcher script that first links the node_modules tree before running the program.

Bazel always runs actions with a working directory set to your workspace root. If your tool needs to run in a different directory, you can write a process.chdir helper script and invoke it before the action with a --require argument, like args = ["--node_options=--require=./$(execpath chdir.js)"] See rules_nodejs/internal/node/test/chdir for an example.

This is a great candidate to wrap with a macro, as documented: https://docs.bazel.build/versions/master/skylark/macros.html#full-example

PARAMETERS

a label for a binary to run, like @npm//terser/bin:terser. This is the longer form of package/package_bin. Note that you can also refer to a binary in your local workspace.

Defaults to None

an npm package whose binary to run, like “terser”. Assumes your node_modules are installed in a workspace called “npm”

Defaults to None

the “bin” entry from package that should be run. By default package_bin is the same string as package

Defaults to None

similar to genrule.srcs may also include targets that produce or reference npm packages which are needed by the tool

Defaults to []

similar to genrule.outs

Defaults to []

Command-line arguments to the tool.

Subject to ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.

Predefined source/output path substitions is applied first:

See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_label_variables.

Use $(execpath) $(execpaths) to expand labels to the execroot (where Bazel runs build actions).

Use $(rootpath) $(rootpaths) to expand labels to the runfiles path that a built binary can use to find its dependencies.

Since npm_package_bin is used primarily for build actions, in most cases you'll want to use $(execpath) or $(execpaths) to expand locations.

Using $(location) and $(locations) expansions is not recommended as these are a synonyms for either $(execpath) or $(rootpath) depending on the context.

“Make” variables are expanded second:

Predefined “Make” variables such as $(COMPILATION_MODE) and $(TARGET_CPU) are expanded. See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_variables.

Like genrule, you may also use some syntax sugar for locations.

$@: if you have only one output file, the location of the output
$(@D): The output directory. If output_dir=False and there is only one file name in outs, this expands to the directory containing that file. If there are multiple files, this instead expands to the package's root directory in the genfiles tree, even if all generated files belong to the same subdirectory! If output_dir=True then this corresponds to the output directory which is the $(RULEDIR)/{target_name}.
$(RULEDIR): the root output directory of the rule, corresponding with its package (can be used with output_dir=True or False)

See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_genrule_variables.

Defaults to []

set to True if you want the output to be a directory Exactly one of outs, output_dir may be used. If you output a directory, there can only be one output, which will be a directory named the same as the target.

Defaults to False

Link the workspace root to the bin_dir to support absolute requires like ‘my_wksp/path/to/file’. If source files need to be required then they can be copied to the bin_dir with copy_to_bin.

Defaults to False

params_file

USAGE

Generates a UTF-8 encoded params file from a list of arguments.

Handles variable substitutions for args.

PARAMETERS

Name of the rule.

Path of the output file, relative to this package.

Arguments to concatenate into a params file.

Subject to ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.

Subject to predefined source/output path variables substitutions.

See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_label_variables for more info.

Subject to predefined variables & custom variable substitutions.

Predefined “Make” variables such as $(COMPILATION_MODE) and $(TARGET_CPU) are expanded. See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_variables.

Predefined genrule variables are not supported in this context.

Defaults to []

Data for $(location) expansions in args.

Defaults to []

Line endings to use. One of [“auto”, “unix”, “windows”].

“auto” for platform-determined “unix” for LF “windows” for CRLF

Defaults to "auto"

DeclarationInfo

USAGE

The DeclarationInfo provider allows JS rules to communicate typing information. TypeScript's .d.ts files are used as the interop format for describing types. package.json files are included as well, as TypeScript needs to read the “typings” property.

Do not create DeclarationInfo instances directly, instead use the declaration_info factory function.

Note: historically this was a subset of the string-typed “typescript” provider.

FIELDS

A depset of typings files produced by this rule

A depset of typings files produced by this rule and all its transitive dependencies. This prevents needing an aspect in rules that consume the typings, which improves performance.

A depset of .d.ts files that we should not use to infer JSCompiler types (via tsickle)

JSEcmaScriptModuleInfo

USAGE

JavaScript files (and sourcemaps) that are intended to be consumed by downstream tooling.

They should use modern syntax and ESModules. These files should typically be named “foo.mjs”

Historical note: this was the typescript.es6_sources output

FIELDS

Depset of direct JavaScript files and sourcemaps

Depset of direct and transitive JavaScript files and sourcemaps

JSModuleInfo

USAGE

JavaScript files and sourcemaps.

FIELDS

Depset of direct JavaScript files and sourcemaps

Depset of direct and transitive JavaScript files and sourcemaps

JSNamedModuleInfo

USAGE

JavaScript files whose module name is self-contained.

For example named AMD/UMD or goog.module format. These files can be efficiently served with the concatjs bundler. These outputs should be named “foo.umd.js” (note that renaming it from “foo.js” doesn't affect the module id)

Historical note: this was the typescript.es5_sources output.

FIELDS

Depset of direct JavaScript files and sourcemaps

Depset of direct and transitive JavaScript files and sourcemaps

LinkablePackageInfo

USAGE

The LinkablePackageInfo provider provides information to the linker for linking pkg_npm built packages

FIELDS

Depset of files in this package (must all be contained within path)

The package name.

Should be the same as name field in the package's package.json.

In the future, the linker may validate that the names match the name in a package.json file.

The path to link to.

Path must be relative to execroot/wksp. It can either an output dir path such as,

bazel-out/<platform>-<build>/bin/path/to/package or bazel-out/<platform>-<build>/bin/external/external_wksp>/path/to/package

or a source file path such as,

path/to/package or external/<external_wksp>/path/to/package

For internal use only

NodeContextInfo

USAGE

Provides data about the build context, like config_setting's

FIELDS

If stamping is enabled

NodeRuntimeDepsInfo

USAGE

Stores runtime dependencies of a nodejs_binary or nodejs_test

These are files that need to be found by the node module resolver at runtime.

Historically these files were passed using the Runfiles mechanism. However runfiles has a big performance penalty of creating a symlink forest with FS API calls for every file in node_modules. It also causes there to be separate node_modules trees under each binary. This prevents user-contributed modules passed as deps[] to a particular action from being found by node module resolver, which expects everything in one tree.

In node, this resolution is done dynamically by assuming a node_modules tree will exist on disk, so we assume node actions/binary/test executions will do the same.

FIELDS

depset of runtime dependency labels

list of labels of packages that provide NpmPackageInfo

NpmPackageInfo

USAGE

Provides information about npm dependencies

FIELDS

Depset of direct source files in this npm package

Depset of direct & transitive source files in this npm package and in its dependencies

The workspace name that this npm package is provided from

declaration_info

USAGE

Constructs a DeclarationInfo including all transitive files needed to type-check from DeclarationInfo providers in a list of deps.

PARAMETERS

list of typings files

list of labels of dependencies where we should collect their DeclarationInfo to pass transitively

Defaults to []

js_ecma_script_module_info

USAGE

Constructs a JSEcmaScriptModuleInfo including all transitive sources from JSEcmaScriptModuleInfo providers in a list of deps.

Returns a single JSEcmaScriptModuleInfo.

PARAMETERS

Defaults to []

js_module_info

USAGE

Constructs a JSModuleInfo including all transitive sources from JSModuleInfo providers in a list of deps.

Returns a single JSModuleInfo.

PARAMETERS

Defaults to []

js_named_module_info

USAGE

Constructs a JSNamedModuleInfo including all transitive sources from JSNamedModuleInfo providers in a list of deps.

Returns a single JSNamedModuleInfo.

PARAMETERS

Defaults to []

run_node

USAGE

Helper to replace ctx.actions.run

This calls node programs with a node_modules directory in place

PARAMETERS

rule context from the calling rule implementation function

list or depset of inputs to the action

list or ctx.actions.Args object containing arguments to pass to the executable

stringy representation of the executable this action will run, eg eg. “my_executable” rather than ctx.executable.my_executable

node_modules_aspect

USAGE

ASPECT ATTRIBUTES

ATTRIBUTES

(Name, {util.mandatoryString(name: “name” doc_string: “A unique name for this target.” type: NAME mandatory: true )}) A unique name for this target.