From ea599a55b2850090d279b45c51c352d4af4528ad Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Thu, 26 Nov 2020 19:22:16 +0000 Subject: [PATCH 1/9] feat(builtin): create symlink for build files present on node modules installed with relative paths test(builtin): test setup attempt for support local linked packages chore(builtin): format fix chore(builtin): format fix chore(builtin): format fix chore(builtin): put back unintended changes test(builtin): correct test implementation feat(builtin): include warning log about not found build file chore(builtin): use specific workspace on local-module one for each package manager fix(builtin): only symlink package if it is inside the workspace chore(builtin): add note about corner case as suggested in the pr review docs(builtin): add docs for new behaviour on npm_install and yarn_install rules --- WORKSPACE | 6 +++ docs/Built-ins.md | 36 ++++++++++++++ internal/npm_install/generate_build_file.ts | 48 +++++++++++++++++-- internal/npm_install/index.js | 19 +++++++- internal/npm_install/test/BUILD.bazel | 1 + internal/npm_install/test/common.spec.js | 4 ++ tools/fine_grained_deps_npm/package-lock.json | 3 ++ tools/fine_grained_deps_npm/package.json | 1 + tools/fine_grained_deps_yarn/package.json | 1 + tools/fine_grained_deps_yarn/yarn.lock | 4 ++ .../npm_packages/local_module/npm/BUILD.bazel | 35 ++++++++++++++ tools/npm_packages/local_module/npm/index.js | 1 + .../local_module/npm/package.json | 4 ++ .../local_module/yarn/BUILD.bazel | 35 ++++++++++++++ tools/npm_packages/local_module/yarn/index.js | 1 + .../local_module/yarn/package.json | 4 ++ 16 files changed, 199 insertions(+), 4 deletions(-) create mode 100644 tools/npm_packages/local_module/npm/BUILD.bazel create mode 100644 tools/npm_packages/local_module/npm/index.js create mode 100644 tools/npm_packages/local_module/npm/package.json create mode 100644 tools/npm_packages/local_module/yarn/BUILD.bazel create mode 100644 tools/npm_packages/local_module/yarn/index.js create mode 100644 tools/npm_packages/local_module/yarn/package.json diff --git a/WORKSPACE b/WORKSPACE index d5a91f6441..81cae65280 100644 --- a/WORKSPACE +++ b/WORKSPACE @@ -189,6 +189,9 @@ local_repository( yarn_install( name = "fine_grained_deps_yarn", data = [ + "//:tools/npm_packages/local_module/yarn/BUILD.bazel", + "//:tools/npm_packages/local_module/yarn/index.js", + "//:tools/npm_packages/local_module/yarn/package.json", "//internal/npm_install/test:postinstall.js", ], environment = { @@ -209,6 +212,9 @@ yarn_install( npm_install( name = "fine_grained_deps_npm", data = [ + "//:tools/npm_packages/local_module/npm/BUILD.bazel", + "//:tools/npm_packages/local_module/npm/index.js", + "//:tools/npm_packages/local_module/npm/package.json", "//internal/npm_install/test:postinstall.js", ], environment = { diff --git a/docs/Built-ins.md b/docs/Built-ins.md index beec2815e3..09d79b3f8c 100755 --- a/docs/Built-ins.md +++ b/docs/Built-ins.md @@ -947,6 +947,24 @@ Defaults to `True` Defaults to `3600` +**LOCAL MODULES** + +When using a monorepo is common to have locally written modules that we both +want to use locally while publicly publishing them. To achieve it, we need +to declare the package with `file:` in the monorepo `package.json` and +define a `BUILD` file for that local package with a `js_library` rule +defining its `package_name` argument. + +Doing what is mentioned above will be creating a link to the previous +created `BUILD` file from the npm external Bazel repository, which require +us to complete a last step which writing the expected targets on that +same `BUILD` file to be later used by the `npm_install` rule, which +are: ``, ``, +``, `` and the last +one just ``. + +If you doubt what those targets should look like, check the +generated `BUILD` file for a given node module. ## pkg_npm @@ -1314,6 +1332,24 @@ Defaults to `True` (*Label, mandatory*) +**LOCAL MODULES** + +When using a monorepo is common to have locally written modules that we both +want to use locally while publicly publishing them. To achieve it, we need +to declare the package with `link:` in the monorepo `package.json` and +define a `BUILD` file for that local package with a `js_library` rule +defining its `package_name` argument. + +Doing what is mentioned above will be creating a link to the previous +created `BUILD` file from the npm external Bazel repository, which require +us to complete a last step which writing the expected targets on that +same `BUILD` file to be later used by the `yarn_install` rule, which +are: ``, ``, +``, `` and the last +one just ``. + +If you doubt what those targets should look like, check the +generated `BUILD` file for a given node module. ## check_bazel_version diff --git a/internal/npm_install/generate_build_file.ts b/internal/npm_install/generate_build_file.ts index e81991f07a..56d080d025 100644 --- a/internal/npm_install/generate_build_file.ts +++ b/internal/npm_install/generate_build_file.ts @@ -93,6 +93,15 @@ function writeFileSync(p: string, content: string) { fs.writeFileSync(p, content); } +/** + * Creates a file symlink, first ensuring that the directory to + * create it into exists. + */ +function createFileSymlinkSync(target: string, p: string) { + mkdirp(path.dirname(p)); + fs.symlinkSync(target, p, 'file'); +} + /** * Main entrypoint. */ @@ -194,11 +203,37 @@ js_library( * Generates all BUILD & bzl files for a package. */ function generatePackageBuildFiles(pkg: Dep) { - // If a BUILD file was shipped with the package, append its contents to the end of - // what we generate for the package. + // If a BUILD file was shipped with the package we should symlink the generated BUILD file + // instead of append its contents to the end of the one we were going to generate. + // https://github.com/bazelbuild/rules_nodejs/issues/2131 let buildFilePath: string|undefined; if (pkg._files.includes('BUILD')) buildFilePath = 'BUILD'; if (pkg._files.includes('BUILD.bazel')) buildFilePath = 'BUILD.bazel'; + + // Recreate the pkg dir inside the node_modules folder + const nodeModulesPkgDir = `node_modules/${pkg._dir}`; + // Check if the current package dep dir is a symlink (which happens when we + // install a node_module with link:) + const isPkgDirASymlink = + fs.existsSync(nodeModulesPkgDir) && fs.lstatSync(nodeModulesPkgDir).isSymbolicLink(); + // Check if the current package is also written inside the workspace + // NOTE: It's a corner case but fs.realpathSync(.) will not be the root of + // the workspace if symlink_node_modules = False as yarn & npm are run in the root of the + // external repository and anything linked with a relative path would have to be copied + // over via that data attribute + const isPkgInsideWorkspace = fs.realpathSync(nodeModulesPkgDir).includes(fs.realpathSync(`.`)); + // Mark build file as one to symlink instead of generate as the package dir is a symlink, we + // have a BUILD file and the pkg is written inside the workspace + const symlinkBuildFile = isPkgDirASymlink && buildFilePath && isPkgInsideWorkspace; + + // Log if a BUILD file was expected but was not found + if (!symlinkBuildFile && isPkgDirASymlink) { + console.log(`[yarn_install/npm_install]: package ${ + nodeModulesPkgDir} is local symlink and as such a BUILD file for it is expected but none was found. Please add one at ${ + fs.realpathSync(nodeModulesPkgDir)}`) + } + + // The following won't be used in a symlink build file case let buildFile = printPackage(pkg); if (buildFilePath) { buildFile = buildFile + '\n' + @@ -256,7 +291,14 @@ exports_files(["index.bzl"]) } } - writeFileSync(path.posix.join(pkg._dir, buildFilePath), generateBuildFileHeader(visibility) + buildFile); + if (!symlinkBuildFile) { + writeFileSync( + path.posix.join(pkg._dir, buildFilePath), generateBuildFileHeader(visibility) + buildFile); + } else { + const realPathBuildFileForPkg = + fs.realpathSync(path.posix.join(nodeModulesPkgDir, buildFilePath)); + createFileSymlinkSync(realPathBuildFileForPkg, path.posix.join(pkg._dir, buildFilePath)); + } } /** diff --git a/internal/npm_install/index.js b/internal/npm_install/index.js index c0a025b923..df341d8f5a 100644 --- a/internal/npm_install/index.js +++ b/internal/npm_install/index.js @@ -39,6 +39,10 @@ function writeFileSync(p, content) { mkdirp(path.dirname(p)); fs.writeFileSync(p, content); } +function createFileSymlinkSync(target, p) { + mkdirp(path.dirname(p)); + fs.symlinkSync(target, p, 'file'); +} function main() { const deps = getDirectDependencySet(PKG_JSON_FILE_PATH); const pkgs = findPackages('node_modules', deps); @@ -113,6 +117,13 @@ function generatePackageBuildFiles(pkg) { buildFilePath = 'BUILD'; if (pkg._files.includes('BUILD.bazel')) buildFilePath = 'BUILD.bazel'; + const nodeModulesPkgDir = `node_modules/${pkg._dir}`; + const isPkgDirASymlink = fs.existsSync(nodeModulesPkgDir) && fs.lstatSync(nodeModulesPkgDir).isSymbolicLink(); + const isPkgInsideWorkspace = fs.realpathSync(nodeModulesPkgDir).includes(fs.realpathSync(`.`)); + const symlinkBuildFile = isPkgDirASymlink && buildFilePath && isPkgInsideWorkspace; + if (!symlinkBuildFile && isPkgDirASymlink) { + console.log(`[yarn_install/npm_install]: package ${nodeModulesPkgDir} is local symlink and as such a BUILD file for it is expected but none was found. Please add one at ${fs.realpathSync(nodeModulesPkgDir)}`); + } let buildFile = printPackage(pkg); if (buildFilePath) { buildFile = buildFile + '\n' + @@ -154,7 +165,13 @@ exports_files(["index.bzl"]) `; } } - writeFileSync(path.posix.join(pkg._dir, buildFilePath), generateBuildFileHeader(visibility) + buildFile); + if (!symlinkBuildFile) { + writeFileSync(path.posix.join(pkg._dir, buildFilePath), generateBuildFileHeader(visibility) + buildFile); + } + else { + const realPathBuildFileForPkg = fs.realpathSync(path.posix.join(nodeModulesPkgDir, buildFilePath)); + createFileSymlinkSync(realPathBuildFileForPkg, path.posix.join(pkg._dir, buildFilePath)); + } } function generateBazelWorkspaces(pkgs) { const workspaces = {}; diff --git a/internal/npm_install/test/BUILD.bazel b/internal/npm_install/test/BUILD.bazel index 286295f9f9..3af37da108 100644 --- a/internal/npm_install/test/BUILD.bazel +++ b/internal/npm_install/test/BUILD.bazel @@ -126,6 +126,7 @@ sh_test( "@fine_grained_deps_%s//jasmine" % pkgmgr, "@fine_grained_deps_%s//jasmine-core" % pkgmgr, "@fine_grained_deps_%s//ajv" % pkgmgr, + "@fine_grained_deps_%s//local-module" % pkgmgr, "@fine_grained_deps_%s//typescript" % pkgmgr, "@fine_grained_deps_%s//rxjs" % pkgmgr, # Note, test-b depends on test-a@0.0.1 which should be diff --git a/internal/npm_install/test/common.spec.js b/internal/npm_install/test/common.spec.js index a82d6832ff..b731df71f7 100644 --- a/internal/npm_install/test/common.spec.js +++ b/internal/npm_install/test/common.spec.js @@ -15,6 +15,10 @@ describe('dependencies', () => { require('ajv/lib/$data'); }); + it(`should resolve local-module`, () => { + require('local-module'); + }); + it(`should resolve rxjs/src/tsconfig.json`, () => { // the BUILD.bazel file in rxjs/src should have been // deleted by fine grained deps and rxjs/src/tsconfig.json diff --git a/tools/fine_grained_deps_npm/package-lock.json b/tools/fine_grained_deps_npm/package-lock.json index 65038156e4..e5c85d553c 100644 --- a/tools/fine_grained_deps_npm/package-lock.json +++ b/tools/fine_grained_deps_npm/package-lock.json @@ -1288,6 +1288,9 @@ "graceful-fs": "^4.1.9" } }, + "local-module": { + "version": "file:tools/npm_packages/local_module/npm" + }, "lodash.debounce": { "version": "4.0.8", "resolved": "https://registry.npmjs.org/lodash.debounce/-/lodash.debounce-4.0.8.tgz", diff --git a/tools/fine_grained_deps_npm/package.json b/tools/fine_grained_deps_npm/package.json index 756fce271b..77d8e903e1 100644 --- a/tools/fine_grained_deps_npm/package.json +++ b/tools/fine_grained_deps_npm/package.json @@ -12,6 +12,7 @@ "chokidar": "2.0.4", "http-server": "github:alexeagle/http-server#97205e945b69091606ed83aa0c8489e9ce65d282", "klaw": "1.3.1", + "local-module": "file:tools/npm_packages/local_module/npm", "rxjs": "6.5.0" }, "scripts": { diff --git a/tools/fine_grained_deps_yarn/package.json b/tools/fine_grained_deps_yarn/package.json index 756fce271b..54be5a1e9e 100644 --- a/tools/fine_grained_deps_yarn/package.json +++ b/tools/fine_grained_deps_yarn/package.json @@ -12,6 +12,7 @@ "chokidar": "2.0.4", "http-server": "github:alexeagle/http-server#97205e945b69091606ed83aa0c8489e9ce65d282", "klaw": "1.3.1", + "local-module": "link:tools/npm_packages/local_module/yarn", "rxjs": "6.5.0" }, "scripts": { diff --git a/tools/fine_grained_deps_yarn/yarn.lock b/tools/fine_grained_deps_yarn/yarn.lock index babc1065b2..03752e0a23 100644 --- a/tools/fine_grained_deps_yarn/yarn.lock +++ b/tools/fine_grained_deps_yarn/yarn.lock @@ -751,6 +751,10 @@ klaw@1.3.1: optionalDependencies: graceful-fs "^4.1.9" +"local-module@link:tools/npm_packages/local_module/yarn": + version "0.0.0" + uid "" + lodash.debounce@^4.0.8: version "4.0.8" resolved "https://registry.yarnpkg.com/lodash.debounce/-/lodash.debounce-4.0.8.tgz#82d79bff30a67c4005ffd5e2515300ad9ca4d7af" diff --git a/tools/npm_packages/local_module/npm/BUILD.bazel b/tools/npm_packages/local_module/npm/BUILD.bazel new file mode 100644 index 0000000000..7ede7d5b33 --- /dev/null +++ b/tools/npm_packages/local_module/npm/BUILD.bazel @@ -0,0 +1,35 @@ +load("@build_bazel_rules_nodejs//:index.bzl", "js_library") + +package(default_visibility = ["//visibility:public"]) + +SRCS = [ + "index.js", + "package.json", +] + +filegroup( + name = "local-module__files", + srcs = ["@fine_grained_deps_npm//:node_modules/local-module/%s" % file for file in SRCS], +) + +js_library( + name = "local-module", + srcs = [":local-module__files"], + deps = [ + ":local-module__contents", + ], +) + +js_library( + name = "local-module__contents", + srcs = [ + ":local-module__files", + ":local-module__nested_node_modules", + ], + visibility = ["//:__subpackages__"], +) + +filegroup( + name = "local-module__nested_node_modules", + visibility = ["//:__subpackages__"], +) diff --git a/tools/npm_packages/local_module/npm/index.js b/tools/npm_packages/local_module/npm/index.js new file mode 100644 index 0000000000..e8e15eefe1 --- /dev/null +++ b/tools/npm_packages/local_module/npm/index.js @@ -0,0 +1 @@ +module.exports = 'local_module'; diff --git a/tools/npm_packages/local_module/npm/package.json b/tools/npm_packages/local_module/npm/package.json new file mode 100644 index 0000000000..870f1ba6e6 --- /dev/null +++ b/tools/npm_packages/local_module/npm/package.json @@ -0,0 +1,4 @@ +{ + "version": "0.0.1", + "main": "index.js" +} diff --git a/tools/npm_packages/local_module/yarn/BUILD.bazel b/tools/npm_packages/local_module/yarn/BUILD.bazel new file mode 100644 index 0000000000..a899ea4269 --- /dev/null +++ b/tools/npm_packages/local_module/yarn/BUILD.bazel @@ -0,0 +1,35 @@ +load("@build_bazel_rules_nodejs//:index.bzl", "js_library") + +package(default_visibility = ["//visibility:public"]) + +SRCS = [ + "index.js", + "package.json", +] + +filegroup( + name = "local-module__files", + srcs = ["@fine_grained_deps_yarn//:node_modules/local-module/%s" % file for file in SRCS], +) + +js_library( + name = "local-module", + srcs = [":local-module__files"], + deps = [ + ":local-module__contents", + ], +) + +js_library( + name = "local-module__contents", + srcs = [ + ":local-module__files", + ":local-module__nested_node_modules", + ], + visibility = ["//:__subpackages__"], +) + +filegroup( + name = "local-module__nested_node_modules", + visibility = ["//:__subpackages__"], +) diff --git a/tools/npm_packages/local_module/yarn/index.js b/tools/npm_packages/local_module/yarn/index.js new file mode 100644 index 0000000000..e8e15eefe1 --- /dev/null +++ b/tools/npm_packages/local_module/yarn/index.js @@ -0,0 +1 @@ +module.exports = 'local_module'; diff --git a/tools/npm_packages/local_module/yarn/package.json b/tools/npm_packages/local_module/yarn/package.json new file mode 100644 index 0000000000..870f1ba6e6 --- /dev/null +++ b/tools/npm_packages/local_module/yarn/package.json @@ -0,0 +1,4 @@ +{ + "version": "0.0.1", + "main": "index.js" +} From dca6cb0a393a1c1f48902917e34bfa7b9eccaa66 Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Wed, 16 Dec 2020 05:12:52 +0000 Subject: [PATCH 2/9] docs(builtin): update docs with details from that change --- docs/Built-ins.html | 87 +++++++++++++------ docs/Built-ins.md | 121 ++++++++++++++------------- internal/npm_install/npm_install.bzl | 46 +++++++++- 3 files changed, 168 insertions(+), 86 deletions(-) diff --git a/docs/Built-ins.html b/docs/Built-ins.html index 53624b2b71..e999218da6 100755 --- a/docs/Built-ins.html +++ b/docs/Built-ins.html @@ -109,10 +109,6 @@

Rules

-
  • Karma
    • - - -
  • Labs
    • @@ -181,9 +177,9 @@

    node_repositories

    USAGE

    -node_repositories(name, node_repositories, node_urls, node_version, package_json, preserve_symlinks,
-                  repo_mapping, vendored_node, vendored_yarn, yarn_repositories, yarn_urls,
-                  yarn_version)
+node_repositories(name, node_download_auth, node_repositories, node_urls, node_version,
+                  package_json, preserve_symlinks, repo_mapping, vendored_node, vendored_yarn,
+                  yarn_download_auth, yarn_repositories, yarn_urls, yarn_version)

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

    @@ -286,6 +282,13 @@

    name

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

    +

    node_download_auth

    + +

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

    + +

    Defaults to {}

    +

    node_repositories

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

    @@ -354,6 +357,13 @@

    vendored_yarn

    Defaults to None

    +

    yarn_download_auth

    + +

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

    + +

    Defaults to {}

    +

    yarn_repositories

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

    @@ -939,6 +949,26 @@

    npm_install

    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.

    +

    LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL

    + +

    When using a monorepo is common to have locally written modules that we both +want to use locally while publicly publishing them. That is not much of a problem +as we can use a js_library rule with a package_name attribute defined inside the +local package BUILD file. However, if we are in the middle of transition into bazel, +or we have any other requirement to use that local package outside bazel we will also +have to declare and install the local package with file: in the monorepo package.json +dependencies, which could introduce a race condition within the npm_install rule.

    + +

    In order to overcome it, a link will be created to the package BUILD file from the +npm external Bazel repository, which require us to complete a last step which is writing +the expected targets on that same BUILD file to be later used by the npm_install +rule, which are: <package_name__files>, <package_name__nested_node_modules>, +<package_name__contents>, <package_name__typings> and the last +one just <package_name>.

    + +

    If you doubt what those targets should look like, check the +generated BUILD file for a given node module.

    +

    ATTRIBUTES

    name

    @@ -1034,9 +1064,7 @@

    strict_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

    +

    Defaults to True

    @@ -1067,8 +1095,8 @@

    pkg_npm

    USAGE

    -pkg_npm(name, deps, nested_packages, node_context_data, package_name, replace_with_version, srcs,
-        substitutions, vendor_external)
+pkg_npm(name, deps, nested_packages, node_context_data, package_name, srcs, substitutions,
+        vendor_external)

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

    @@ -1164,17 +1192,6 @@

    package_name

    Defaults to ""

    -

    replace_with_version

    - -

    (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"

    -

    srcs

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

    @@ -1264,6 +1281,26 @@

    yarn_install

    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.

    +

    LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL

    + +

    When using a monorepo is common to have locally written modules that we both +want to use locally while publicly publishing them. That is not much of a problem +as we can use a js_library rule with a package_name attribute defined inside the +local package BUILD file. However, if we are in the middle of transition into bazel, +or we have any other requirement to use that local package outside bazel we will also +have to declare and install the local package with link: in the monorepo package.json +dependencies, which could introduce a race condition within the yarn_install rule.

    + +

    In order to overcome it, a link will be created to the package BUILD file from the +npm external Bazel repository, which require us to complete a last step which is writing +the expected targets on that same BUILD file to be later used by the yarn_install +rule, which are: <package_name__files>, <package_name__nested_node_modules>, +<package_name__contents>, <package_name__typings> and the last +one just <package_name>.

    + +

    If you doubt what those targets should look like, check the +generated BUILD file for a given node module.

    +

    ATTRIBUTES

    name

    @@ -1355,9 +1392,7 @@

    strict_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

    +

    Defaults to True

    diff --git a/docs/Built-ins.md b/docs/Built-ins.md index 09d79b3f8c..f52aa50e62 100755 --- a/docs/Built-ins.md +++ b/docs/Built-ins.md @@ -22,9 +22,9 @@ These rules are available without any npm installation, via the `WORKSPACE` inst **USAGE** 
    -node_repositories(name, node_repositories, node_urls, node_version, package_json, preserve_symlinks,
-                  repo_mapping, vendored_node, vendored_yarn, yarn_repositories, yarn_urls,
-                  yarn_version)
+node_repositories(name, node_download_auth, node_repositories, node_urls, node_version,
+                  package_json, preserve_symlinks, repo_mapping, vendored_node, vendored_yarn,
+                  yarn_download_auth, yarn_repositories, yarn_urls, yarn_version)
    To be run in user's WORKSPACE to install rules_nodejs dependencies. @@ -142,6 +142,13 @@ Note that the dependency installation scripts will run in each subpackage indica (*Name, mandatory*): A unique name for this repository. +

    node_download_auth

    + +(*Dictionary: String -> String*): auth to use for all url requests +Example: {"type": "basic", "login": "", "password": "" } + +Defaults to `{}` +

    node_repositories

    (*Dictionary: String -> List of strings*): Custom list of node repositories to use @@ -211,6 +218,13 @@ Defaults to `None` Defaults to `None` +

    yarn_download_auth

    + +(*Dictionary: String -> String*): auth to use for all url requests +Example: {"type": "basic", "login": "", "password": "" } + +Defaults to `{}` +

    yarn_repositories

    (*Dictionary: String -> List of strings*): Custom list of yarn repositories to use. @@ -819,6 +833,27 @@ This rule will set the environment variable `BAZEL_NPM_INSTALL` to '1' (unless i 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. + +**LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL** + +When using a monorepo is common to have locally written modules that we both +want to use locally while publicly publishing them. That is not much of a problem +as we can use a `js_library` rule with a `package_name` attribute defined inside the +local package `BUILD` file. However, if we are in the middle of transition into bazel, +or we have any other requirement to use that local package outside bazel we will also +have to declare and install the local package with `file:` in the monorepo `package.json` +dependencies, which could introduce a race condition within the `npm_install rule`. + +In order to overcome it, a link will be created to the package `BUILD` file from the +npm external Bazel repository, which require us to complete a last step which is writing +the expected targets on that same `BUILD` file to be later used by the `npm_install` +rule, which are: ``, ``, +``, `` and the last +one just ``. + +If you doubt what those targets should look like, check the +generated `BUILD` file for a given node module. + **ATTRIBUTES** @@ -919,9 +954,7 @@ When enabled, only dependencies within the given `package.json` file are given p 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` +Defaults to `True` @@ -947,24 +980,6 @@ Defaults to `True` Defaults to `3600` -**LOCAL MODULES** - -When using a monorepo is common to have locally written modules that we both -want to use locally while publicly publishing them. To achieve it, we need -to declare the package with `file:` in the monorepo `package.json` and -define a `BUILD` file for that local package with a `js_library` rule -defining its `package_name` argument. - -Doing what is mentioned above will be creating a link to the previous -created `BUILD` file from the npm external Bazel repository, which require -us to complete a last step which writing the expected targets on that -same `BUILD` file to be later used by the `npm_install` rule, which -are: ``, ``, -``, `` and the last -one just ``. - -If you doubt what those targets should look like, check the -generated `BUILD` file for a given node module. ## pkg_npm @@ -972,8 +987,8 @@ generated `BUILD` file for a given node module. **USAGE** 
    -pkg_npm(name, deps, nested_packages, node_context_data, package_name, replace_with_version, srcs,
-        substitutions, vendor_external)
+pkg_npm(name, deps, nested_packages, node_context_data, package_name, srcs, substitutions,
+        vendor_external)
    The pkg_npm rule creates a directory containing a publishable npm artifact. @@ -1078,17 +1093,6 @@ Defaults to `@build_bazel_rules_nodejs//internal:node_context_data` Defaults to `""` -

    replace_with_version

    - -(*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"` -

    srcs

    (*List of labels*): Files inside this directory which are simply copied into the package. @@ -1185,6 +1189,27 @@ This rule will set the environment variable `BAZEL_YARN_INSTALL` to '1' (unless 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. + +**LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL** + +When using a monorepo is common to have locally written modules that we both +want to use locally while publicly publishing them. That is not much of a problem +as we can use a `js_library` rule with a `package_name` attribute defined inside the +local package `BUILD` file. However, if we are in the middle of transition into bazel, +or we have any other requirement to use that local package outside bazel we will also +have to declare and install the local package with `link:` in the monorepo `package.json` +dependencies, which could introduce a race condition within the `yarn_install rule`. + +In order to overcome it, a link will be created to the package `BUILD` file from the +npm external Bazel repository, which require us to complete a last step which is writing +the expected targets on that same `BUILD` file to be later used by the `yarn_install` +rule, which are: ``, ``, +``, `` and the last +one just ``. + +If you doubt what those targets should look like, check the +generated `BUILD` file for a given node module. + **ATTRIBUTES** @@ -1280,9 +1305,7 @@ When enabled, only dependencies within the given `package.json` file are given p 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` +Defaults to `True` @@ -1332,24 +1355,6 @@ Defaults to `True` (*Label, mandatory*) -**LOCAL MODULES** - -When using a monorepo is common to have locally written modules that we both -want to use locally while publicly publishing them. To achieve it, we need -to declare the package with `link:` in the monorepo `package.json` and -define a `BUILD` file for that local package with a `js_library` rule -defining its `package_name` argument. - -Doing what is mentioned above will be creating a link to the previous -created `BUILD` file from the npm external Bazel repository, which require -us to complete a last step which writing the expected targets on that -same `BUILD` file to be later used by the `yarn_install` rule, which -are: ``, ``, -``, `` and the last -one just ``. - -If you doubt what those targets should look like, check the -generated `BUILD` file for a given node module. ## check_bazel_version diff --git a/internal/npm_install/npm_install.bzl b/internal/npm_install/npm_install.bzl index c74b9533e7..dda67d3daf 100644 --- a/internal/npm_install/npm_install.bzl +++ b/internal/npm_install/npm_install.bzl @@ -312,7 +312,28 @@ See npm CLI docs https://docs.npmjs.com/cli/install.html for complete list of su 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.""", +check if yarn is being run by the `npm_install` repository rule. + + +**LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL** + +When using a monorepo is common to have locally written modules that we both +want to use locally while publicly publishing them. That is not much of a problem +as we can use a `js_library` rule with a `package_name` attribute defined inside the +local package `BUILD` file. However, if we are in the middle of transition into bazel, +or we have any other requirement to use that local package outside bazel we will also +have to declare and install the local package with `file:` in the monorepo `package.json` +dependencies, which could introduce a race condition within the `npm_install rule`. + +In order to overcome it, a link will be created to the package `BUILD` file from the +npm external Bazel repository, which require us to complete a last step which is writing +the expected targets on that same `BUILD` file to be later used by the `npm_install` +rule, which are: ``, ``, +``, `` and the last +one just ``. + +If you doubt what those targets should look like, check the +generated `BUILD` file for a given node module.""", implementation = _npm_install_impl, ) @@ -454,6 +475,27 @@ to yarn so that the local cache is contained within the external repository. 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.""", +check if yarn is being run by the `yarn_install` repository rule. + + +**LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL** + +When using a monorepo is common to have locally written modules that we both +want to use locally while publicly publishing them. That is not much of a problem +as we can use a `js_library` rule with a `package_name` attribute defined inside the +local package `BUILD` file. However, if we are in the middle of transition into bazel, +or we have any other requirement to use that local package outside bazel we will also +have to declare and install the local package with `link:` in the monorepo `package.json` +dependencies, which could introduce a race condition within the `yarn_install rule`. + +In order to overcome it, a link will be created to the package `BUILD` file from the +npm external Bazel repository, which require us to complete a last step which is writing +the expected targets on that same `BUILD` file to be later used by the `yarn_install` +rule, which are: ``, ``, +``, `` and the last +one just ``. + +If you doubt what those targets should look like, check the +generated `BUILD` file for a given node module.""", implementation = _yarn_install_impl, ) From 6c2b41f3b8ccc2f6a59c758be81cadad900f3d8c Mon Sep 17 00:00:00 2001 From: Tiago Costa Date: Wed, 16 Dec 2020 05:24:22 +0000 Subject: [PATCH 3/9] docs(builtin): restore old source for builtin doc generated files --- docs/Built-ins.html | 2617 +++++++++++++++++++++---------------------- docs/Built-ins.md | 43 - 2 files changed, 1288 insertions(+), 1372 deletions(-) diff --git a/docs/Built-ins.html b/docs/Built-ins.html index e999218da6..5f0397209d 100755 --- a/docs/Built-ins.html +++ b/docs/Built-ins.html @@ -1,212 +1,212 @@ - - - - - + + + + + - rules_nodejs - Built-ins + rules_nodejs - Built-ins - - + + - - + + - - + + - - - + + + - - + + - - - + + +
    -
    -
    - - - -
    +
    +
    + + + +
    + + +
    +
    + +

    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

    + + 
     node_repositories(name, node_download_auth, node_repositories, node_urls, node_version,
                   package_json, preserve_symlinks, repo_mapping, vendored_node, vendored_yarn,
                   yarn_download_auth, yarn_repositories, yarn_urls, yarn_version)
    -

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

    +

    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

    +

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

    -

    Simplest Usage

    +

    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.

    +

    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)

    +

    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)

    +

    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

    +

    Using a custom version

    -

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

    +

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

    -

    Custom NodeJS versions

    +

    Custom NodeJS versions

    -

    To specify custom NodeJS versions, use the node_repositories attribute

    +

    To specify custom NodeJS versions, use the node_repositories attribute

    -
    node_repositories(
+                
    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"),
@@ -215,32 +215,32 @@ 
    Custom NodeJS versions
    
 )
 
    
 
-
    These can be mapped to a custom download URL, using node_urls
    
+                
    These can be mapped to a custom download URL, using node_urls
    
 
-
    node_repositories(
+                
    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
    
+                
    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
    
+                
    Custom Yarn versions
    
 
-
    To specify custom Yarn versions, use the yarn_repositories attribute
    
+                
    To specify custom Yarn versions, use the yarn_repositories attribute
    
 
-
    node_repositories(
+                
    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
    
+                
    Like node_urls, the yarn_urls attribute can be used to provide a list of custom URLs to use to download yarn
    
 
-
    node_repositories(
+                
    node_repositories(
     yarn_repositories = {
         "1.12.1": ("yarn-v1.12.1.tar.gz", "yarn-v1.12.1", "09bea8f4ec41e9079fa03093d3b2db7ac5c5331852236d63815f8df42b3ba88d"),
     },
@@ -251,210 +251,210 @@ 
    Custom Yarn versions
    
 )
 
    
 
-
    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.
    
+                
    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
    
+                
    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.
    
+                
    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.
    
+                
    See the the repositories documentation for how to use the resulting repositories.
    
 
-
    Manual install
    
+                
    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.
    
+                
    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")
+                
    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.
    
+                
    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.
    
+                
    Note that the dependency installation scripts will run in each subpackage indicated by the package_json attribute.
    
 
-
    ATTRIBUTES
    
+                
    ATTRIBUTES
    
 
-
    name
    
+                
    name
    
 
-
    (Name, mandatory): A unique name for this repository.
    
+                
    (Name, mandatory): A unique name for this repository.
    
 
-
    node_download_auth
    
+                
    node_download_auth
    
 
-
    (Dictionary: String -> String): auth to use for all url requests
-Example: {“type”: “basic”, “login”: “", "password": "" }
    
+                
    (Dictionary: String -> String): auth to use for all url requests
+                    Example: {“type”: “basic”, “login”: “", "password": "" }
    
 
-
    Defaults to {}
    
+                
    Defaults to {}
    
 
-
    node_repositories
    
+                
    node_repositories
    
 
-
    (Dictionary: String -> List of strings): Custom list of node repositories to use
    
+                
    (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.
    
+                
    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.
    
+                
    By default, if this attribute has no items, we’ll use a list of all public NodeJS releases.
    
 
-
    Defaults to {}
    
+                
    Defaults to {}
    
 
-
    node_urls
    
+                
    node_urls
    
 
-
    (List of strings): custom list of URLs to use to download NodeJS
    
+                
    (List of strings): custom list of URLs to use to download NodeJS
    
 
-
    Each entry is a template for downloading a node distribution.
    
+                
    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.
    
+                
    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}"]
    
+                
    Defaults to ["https://mirror.bazel.build/nodejs.org/dist/v{version}/{filename}", "https://nodejs.org/dist/v{version}/{filename}"]
    
 
-
    node_version
    
+                
    node_version
    
 
-
    (String): the specific version of NodeJS to install or, if vendored_node is specified, the vendored version of node
    
+                
    (String): the specific version of NodeJS to install or, if vendored_node is specified, the vendored version of node
    
 
-
    Defaults to "12.13.0"
    
+                
    Defaults to "12.13.0"
    
 
-
    package_json
    
+                
    package_json
    
 
-
    (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.
    
+                
    (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 []
    
+                
    Defaults to []
    
 
-
+                
 
-
    (Boolean): Turn on –node_options=–preserve-symlinks for nodejs_binary and nodejs_test rules.
    
+                
    (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.
    
+                
    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
    
+                
    Defaults to True
    
 
-
    repo_mapping
    
+                
    repo_mapping
    
 
-
    (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.<p>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).
    
+                
    (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.<p>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).
    
 
-
    vendored_node
    
+                
    vendored_node
    
 
-
    (Label): the local path to a pre-installed NodeJS runtime.
    
+                
    (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.
    
+                
    If set then also set node_version to the version that of node that is vendored.
    
 
-
    Defaults to None
    
+                
    Defaults to None
    
 
-
    vendored_yarn
    
+                
    vendored_yarn
    
 
-
    (Label): the local path to a pre-installed yarn tool
    
+                
    (Label): the local path to a pre-installed yarn tool
    
 
-
    Defaults to None
    
+                
    Defaults to None
    
 
-
    yarn_download_auth
    
+                
    yarn_download_auth
    
 
-
    (Dictionary: String -> String): auth to use for all url requests
-Example: {“type”: “basic”, “login”: “", "password": "" }
    
+                
    (Dictionary: String -> String): auth to use for all url requests
+                    Example: {“type”: “basic”, “login”: “", "password": "" }
    
 
-
    Defaults to {}
    
+                
    Defaults to {}
    
 
-
    yarn_repositories
    
+                
    yarn_repositories
    
 
-
    (Dictionary: String -> List of strings): Custom list of yarn repositories to use.
    
+                
    (Dictionary: String -> List of strings): Custom list of yarn repositories to use.
    
 
-
    Dictionary mapping Yarn versions to their corresponding (filename, strip_prefix, sha256) tuples.
    
+                
    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.
    
+                
    By default, if this attribute has no items, we’ll use a list of all public NodeJS releases.
    
 
-
    Defaults to {}
    
+                
    Defaults to {}
    
 
-
    yarn_urls
    
+                
    yarn_urls
    
 
-
    (List of strings): custom list of URLs to use to download Yarn
    
+                
    (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.
    
+                
    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}"]
    
+                
    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}"]
    
 
-
    yarn_version
    
+                
    yarn_version
    
 
-
    (String): the specific version of Yarn to install
    
+                
    (String): the specific version of Yarn to install
    
 
-
    Defaults to "1.19.1"
    
+                
    Defaults to "1.19.1"
    
 
-
    nodejs_binary
    
+                
    nodejs_binary
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     nodejs_binary(name, configuration_env_vars, data, default_env_vars, entry_point,
               link_workspace_root, node_modules, templated_args)
 
    
 
-
    Runs some JavaScript code in NodeJS.
    
+                
    Runs some JavaScript code in NodeJS.
    
 
-
    ATTRIBUTES
    
+                
    ATTRIBUTES
    
 
-
    name
    
+                
    name
    
 
-
    (Name, mandatory): A unique name for this target.
    
+                
    (Name, mandatory): A unique name for this target.
    
 
-
    configuration_env_vars
    
+                
    configuration_env_vars
    
 
-
    (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.
    
+                
    (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 []
    
+                
    Defaults to []
    
 
-
    data
    
+                
    data
    
 
-
    (List of labels): Runtime dependencies which may be loaded during execution.
    
+                
    (List of labels): Runtime dependencies which may be loaded during execution.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    default_env_vars
    
+                
    default_env_vars
    
 
-
    (List of strings): Default environment variables that are added to configuration_env_vars.
    
+                
    (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.
    
+                
    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:
    
+                
    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
      • 
-
    
+                
      
+                    
    • 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"]
    
+                
    Defaults to ["VERBOSE_LOGS", "NODE_DEBUG", "RUNFILES_LIB_DEBUG"]
    
 
-
    entry_point
    
+                
    entry_point
    
 
-
    (Label, mandatory): The script which should be executed first, usually containing a main function.
    
+                
    (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:
    
+                
    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(
+                
    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:
    
+                
    You can specify the entry point as a typescript file so long as you also include
+                    the ts_library target in data:
    
 
-
    ts_library(
+                
    ts_library(
     name = "main",
     srcs = ["main.ts"],
 )
@@ -466,12 +466,12 @@ 
    entry_point
    
 )
 
    
 
-
    The rule will use the corresponding .js output of the ts_library rule as the entry point.
    
+                
    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:
    
+                
    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(
+                
    filegroup(
     name = "entry_file",
     srcs = ["main.js"],
 )
@@ -482,45 +482,45 @@ 
    entry_point
    
 )
 
    
 
-
    The entry_point can also be a label in another workspace:
    
+                
    The entry_point can also be a label in another workspace:
    
 
-
    nodejs_binary(
+                
    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.
    
+                
    (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
    
+                
    Defaults to False
    
 
-
    node_modules
    
+                
    node_modules
    
 
-
    (Label): The npm packages which should be available to require() during
-        execution.
    
+                
    (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,
    
+                
    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(
+                
    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:
    
+                
    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(
+                
    nodejs_binary(
     name = "my_binary",
     ...
     data = [
@@ -531,25 +531,25 @@ 
    node_modules
    
 )
 
    
 
-
    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).
    
+                
    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:
    
+                
    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”,
-)
    
+                
    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:
    
+                
    For other rules such as jasmine_node_test, fine grained
+                    npm dependencies are specified in the deps attribute:
    
 
-
    jasmine_node_test(
+                
    jasmine_node_test(
     name = "my_test",
     ...
     deps = [
@@ -561,48 +561,48 @@ 
    node_modules
    
 )
 
    
 
-
    Defaults to //:node_modules_none
    
+                
    Defaults to //:node_modules_none
    
 
-
    templated_args
    
+                
    templated_args
    
 
-
    (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.
    
+                
    (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 ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.
    
 
-
      
-  
    1. Subject to predefined source/output path variables substitutions.
      2. 
-
    
+                
      
+                    
    1. Subject to predefined source/output path variables substitutions.
      2. 
+                
    
 
-
    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.
    
+                
    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.
    
+                
    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.
    
+                
    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).
    
+                
    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:
    
+                
    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(
+                
    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:
    
+                
    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(
+                
    BUILD.bazel:
    
+                
    nodejs_test(
     name = "my_test",
     data = [":some_file"],
     entry_point = ":my_test.js",
@@ -610,134 +610,134 @@ 
    templated_args
    
 )
 
    
 
-
    my_test.js
    
-
    const runfiles = require(process.env['BAZEL_NODE_RUNFILES_HELPER']);
+                
    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.
    
+                
    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.
    
+                
    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.
    
+                
    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.
    
 
-
      
-  
    1. Subject to predefined variables & custom variable substitutions.
      2. 
-
    
+                
      
+                    
    1. Subject to predefined variables & custom variable substitutions.
      2. 
+                
    
 
-
    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 “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.
    
+                
    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.
    
+                
    Predefined genrule variables are not supported in this context.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    nodejs_test
    
+                
    nodejs_test
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     nodejs_test(name, configuration_env_vars, data, default_env_vars, entry_point, expected_exit_code,
             link_workspace_root, node_modules, templated_args)
 
    
 
-
    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.
    
+                
    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
    
+                
    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.
    
+                
    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.
    
+                
    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
+                
    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.
    
+                
    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
    
+                
    ATTRIBUTES
    
 
-
    name
    
+                
    name
    
 
-
    (Name, mandatory): A unique name for this target.
    
+                
    (Name, mandatory): A unique name for this target.
    
 
-
    configuration_env_vars
    
+                
    configuration_env_vars
    
 
-
    (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.
    
+                
    (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 []
    
+                
    Defaults to []
    
 
-
    data
    
+                
    data
    
 
-
    (List of labels): Runtime dependencies which may be loaded during execution.
    
+                
    (List of labels): Runtime dependencies which may be loaded during execution.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    default_env_vars
    
+                
    default_env_vars
    
 
-
    (List of strings): Default environment variables that are added to configuration_env_vars.
    
+                
    (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.
    
+                
    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:
    
+                
    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
      • 
-
    
+                
      
+                    
    • 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"]
    
+                
    Defaults to ["VERBOSE_LOGS", "NODE_DEBUG", "RUNFILES_LIB_DEBUG"]
    
 
-
    entry_point
    
+                
    entry_point
    
 
-
    (Label, mandatory): The script which should be executed first, usually containing a main function.
    
+                
    (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:
    
+                
    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(
+                
    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:
    
+                
    You can specify the entry point as a typescript file so long as you also include
+                    the ts_library target in data:
    
 
-
    ts_library(
+                
    ts_library(
     name = "main",
     srcs = ["main.ts"],
 )
@@ -749,12 +749,12 @@ 
    entry_point
    
 )
 
    
 
-
    The rule will use the corresponding .js output of the ts_library rule as the entry point.
    
+                
    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:
    
+                
    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(
+                
    filegroup(
     name = "entry_file",
     srcs = ["main.js"],
 )
@@ -765,51 +765,51 @@ 
    entry_point
    
 )
 
    
 
-
    The entry_point can also be a label in another workspace:
    
+                
    The entry_point can also be a label in another workspace:
    
 
-
    nodejs_binary(
+                
    nodejs_binary(
     name = "history-server",
     entry_point = "@npm//:node_modules/history-server/modules/cli.js",
     data = ["@npm//history-server"],
 )
 
    
 
-
    expected_exit_code
    
+                
    expected_exit_code
    
 
-
    (Integer): The expected exit code for the test. Defaults to 0.
    
+                
    (Integer): The expected exit code for the test. Defaults to 0.
    
 
-
    Defaults to 0
    
+                
    Defaults to 0
    
 
-
+                
 
-
    (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.
    
+                
    (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
    
+                
    Defaults to False
    
 
-
    node_modules
    
+                
    node_modules
    
 
-
    (Label): The npm packages which should be available to require() during
-        execution.
    
+                
    (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,
    
+                
    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(
+                
    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:
    
+                
    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(
+                
    nodejs_binary(
     name = "my_binary",
     ...
     data = [
@@ -820,25 +820,25 @@ 
    node_modules
    
 )
 
    
 
-
    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).
    
+                
    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:
    
+                
    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”,
-)
    
+                
    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:
    
+                
    For other rules such as jasmine_node_test, fine grained
+                    npm dependencies are specified in the deps attribute:
    
 
-
    jasmine_node_test(
+                
    jasmine_node_test(
     name = "my_test",
     ...
     deps = [
@@ -850,48 +850,48 @@ 
    node_modules
    
 )
 
    
 
-
    Defaults to //:node_modules_none
    
+                
    Defaults to //:node_modules_none
    
 
-
    templated_args
    
+                
    templated_args
    
 
-
    (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.
    
+                
    (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 ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.
    
 
-
      
-  
    1. Subject to predefined source/output path variables substitutions.
      2. 
-
    
+                
      
+                    
    1. Subject to predefined source/output path variables substitutions.
      2. 
+                
    
 
-
    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.
    
+                
    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.
    
+                
    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.
    
+                
    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).
    
+                
    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:
    
+                
    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(
+                
    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:
    
+                
    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(
+                
    BUILD.bazel:
    
+                
    nodejs_test(
     name = "my_test",
     data = [":some_file"],
     entry_point = ":my_test.js",
@@ -899,211 +899,191 @@ 
    templated_args
    
 )
 
    
 
-
    my_test.js
    
-
    const runfiles = require(process.env['BAZEL_NODE_RUNFILES_HELPER']);
+                
    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.
    
+                
    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.
    
+                
    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.
    
+                
    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.
    
 
-
      
-  
    1. Subject to predefined variables & custom variable substitutions.
      2. 
-
    
+                
      
+                    
    1. Subject to predefined variables & custom variable substitutions.
      2. 
+                
    
 
-
    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 “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.
    
+                
    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.
    
+                
    Predefined genrule variables are not supported in this context.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    npm_install
    
+                
    npm_install
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     npm_install(name, args, data, environment, included_files, manual_build_file_contents, package_json,
             package_lock_json, quiet, repo_mapping, strict_visibility, symlink_node_modules, timeout)
 
    
 
-
    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.
    
-
-
    LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL
    
-
-
    When using a monorepo is common to have locally written modules that we both
-want to use locally while publicly publishing them. That is not much of a problem
-as we can use a js_library rule with a package_name attribute defined inside the
-local package BUILD file. However, if we are in the middle of transition into bazel,
-or we have any other requirement to use that local package outside bazel we will also
-have to declare and install the local package with file: in the monorepo package.json
-dependencies, which could introduce a race condition within the npm_install rule.
    
-
-
    In order to overcome it, a link will be created to the package BUILD file from the
-npm external Bazel repository, which require us to complete a last step which is writing
-the expected targets on that same BUILD file to be later used by the npm_install
-rule, which are: <package_name__files>, <package_name__nested_node_modules>,
-<package_name__contents>, <package_name__typings> and the last
-one just <package_name>.
    
+                
    Runs npm install during workspace setup.
    
 
-
    If you doubt what those targets should look like, check the
-generated BUILD file for a given node module.
    
+                
    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
    
+                
    ATTRIBUTES
    
 
-
    name
    
+                
    name
    
 
-
    (Name, mandatory): A unique name for this repository.
    
+                
    (Name, mandatory): A unique name for this repository.
    
 
-
    args
    
+                
    args
    
 
-
    (List of strings): Arguments passed to npm install.
    
+                
    (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.
    
+                
    See npm CLI docs https://docs.npmjs.com/cli/install.html for complete list of supported arguments.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    data
    
+                
    data
    
 
-
    (List of labels): Data files required by this rule.
    
+                
    (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 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.
    
+                
    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 []
    
+                
    Defaults to []
    
 
-
    environment
    
+                
    environment
    
 
-
    (Dictionary: String -> String): Environment variables to set before calling the package manager.
    
+                
    (Dictionary: String -> String): Environment variables to set before calling the package manager.
    
 
-
    Defaults to {}
    
+                
    Defaults to {}
    
 
-
    included_files
    
+                
    included_files
    
 
-
    (List of strings): List of file extensions to be included in the npm package targets.
    
+                
    (List of strings): List of file extensions to be included in the npm package targets.
    
 
-
    For example, [“.js”, “.d.ts”, “.proto”, “.json”, “”].
    
+                
    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 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.
    
+                
    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.
    
+                
    This attribute applies to both the coarse @wksp//:node_modules target
+                    as well as the fine grained targets such as @wksp//foo.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    manual_build_file_contents
    
+                
    manual_build_file_contents
    
 
-
    (String): Experimental attribute that can be used to override the generated BUILD.bazel file and set its contents manually.
    
+                
    (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.
    
+                
    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 ""
    
+                
    Defaults to ""
    
 
-
    package_json
    
+                
    package_json
    
 
-
    (Label, mandatory)
    
+                
    (Label, mandatory)
    
 
-
    package_lock_json
    
+                
    package_lock_json
    
 
-
    (Label, mandatory)
    
+                
    (Label, mandatory)
    
 
-
    quiet
    
+                
    quiet
    
 
-
    (Boolean): If stdout and stderr should be printed to the terminal.
    
+                
    (Boolean): If stdout and stderr should be printed to the terminal.
    
 
-
    Defaults to True
    
+                
    Defaults to True
    
 
-
    repo_mapping
    
+                
    repo_mapping
    
 
-
    (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.<p>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).
    
+                
    (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.<p>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).
    
 
-
    strict_visibility
    
+                
    strict_visibility
    
 
-
    (Boolean): Turn on stricter visibility for generated BUILD.bazel files
    
+                
    (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.
    
+                
    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.
    
 
-
    Defaults to True
    
+                
    Defaults to True
    
 
-
+                
 
-
    (Boolean): Turn symlinking of node_modules on
    
+                
    (Boolean): Turn symlinking of node_modules on
    
 
-
    This requires the use of Bazel 0.26.0 and the experimental
-managed_directories feature.
    
+                
    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 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.
    
+                
    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
    
+                
    Defaults to True
    
 
-
    timeout
    
+                
    timeout
    
 
-
    (Integer): Maximum duration of the package manager execution in seconds.
    
+                
    (Integer): Maximum duration of the package manager execution in seconds.
    
 
-
    Defaults to 3600
    
+                
    Defaults to 3600
    
 
-
    pkg_npm
    
+                
    pkg_npm
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     pkg_npm(name, deps, nested_packages, node_context_data, package_name, srcs, substitutions,
         vendor_external)
 
    
 
-
    The pkg_npm rule creates a directory containing a publishable npm artifact.
    
+                
    The pkg_npm rule creates a directory containing a publishable npm artifact.
    
 
-
    Example:
    
+                
    Example:
    
 
-
    load("@build_bazel_rules_nodejs//:index.bzl", "pkg_npm")
+                
    load("@build_bazel_rules_nodejs//:index.bzl", "pkg_npm")
 
 pkg_npm(
     name = "my_package",
@@ -1113,10 +1093,10 @@ 
    pkg_npm
    
 )
 
    
 
-
    You can use a pair of // BEGIN-INTERNAL ... // END-INTERNAL comments to mark regions of files that should be elided during publishing.
-For example:
    
+                
    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() {
+                
    function doThing() {
     // BEGIN-INTERNAL
     // This is a secret internal-only comment
     doInternalOnlyThing();
@@ -1124,465 +1104,445 @@ 
    pkg_npm
    
 }
 
    
 
-
    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
    
+                
    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:
    
+                
    Usage:
    
 
-
    pkg_npm yields three labels. Build the package directory using the default label:
    
+                
    pkg_npm yields three labels. Build the package directory using the default label:
    
 
-
    $ bazel build :my_package
+                
    $ 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):
    
+                
    Dry-run of publishing to npm, calling npm pack (it builds the package first if needed):
    
 
-
    $ bazel run :my_package.pack
+                
    $ 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):
    
+                
    Actually publish the package with npm publish (also builds first):
    
 
-
    # Check login credentials
+                
    # 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:
    
+                
    You can pass arguments to npm by escaping them from Bazel using a double-hyphen, for example:
    
 
-
    bazel run my_package.publish -- --tag=next
    
+                
    bazel run my_package.publish -- --tag=next
    
 
-
    ATTRIBUTES
    
+                
    ATTRIBUTES
    
 
-
    name
    
+                
    name
    
 
-
    (Name, mandatory): A unique name for this target.
    
+                
    (Name, mandatory): A unique name for this target.
    
 
-
    deps
    
+                
    deps
    
 
-
    (List of labels): Other targets which produce files that should be included in the package, such as rollup_bundle
    
+                
    (List of labels): Other targets which produce files that should be included in the package, such as rollup_bundle
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    nested_packages
    
+                
    nested_packages
    
 
-
    (List of labels): Other pkg_npm rules whose content is copied into this package.
    
+                
    (List of labels): Other pkg_npm rules whose content is copied into this package.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    node_context_data
    
+                
    node_context_data
    
 
-
    (Label): Provides info about the build context, such as stamping.
    
+                
    (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
    
+                
    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
    
+                
    Defaults to @build_bazel_rules_nodejs//internal:node_context_data
    
 
-
    package_name
    
+                
    package_name
    
 
-
    (String): Optional package_name that this npm package may be imported as.
    
+                
    (String): Optional package_name that this npm package may be imported as.
    
 
-
    Defaults to ""
    
+                
    Defaults to ""
    
 
-
    srcs
    
+                
    srcs
    
 
-
    (List of labels): Files inside this directory which are simply copied into the package.
    
+                
    (List of labels): Files inside this directory which are simply copied into the package.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    substitutions
    
+                
    substitutions
    
 
-
    (Dictionary: String -> String): Key-value pairs which are replaced in all the files while building the package.
    
+                
    (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}"}.
    
+                
    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
    
+                
    See the section on stamping in the README
    
 
-
    Defaults to {}
    
+                
    Defaults to {}
    
 
-
    vendor_external
    
+                
    vendor_external
    
 
-
    (List of strings): External workspaces whose contents should be vendored into this workspace.
-        Avoids external/foo path segments in the resulting package.
    
+                
    (List of strings): External workspaces whose contents should be vendored into this workspace.
+                    Avoids external/foo path segments in the resulting package.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    pkg_web
    
+                
    pkg_web
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     pkg_web(name, additional_root_paths, node_context_data, srcs, substitutions)
 
    
 
-
    Assembles a web application from source files.
    
+                
    Assembles a web application from source files.
    
 
-
    ATTRIBUTES
    
+                
    ATTRIBUTES
    
 
-
    name
    
+                
    name
    
 
-
    (Name, mandatory): A unique name for this target.
    
+                
    (Name, mandatory): A unique name for this target.
    
 
-
    additional_root_paths
    
+                
    additional_root_paths
    
 
-
    (List of strings): Path prefixes to strip off all srcs, in addition to the current package. Longest wins.
    
+                
    (List of strings): Path prefixes to strip off all srcs, in addition to the current package. Longest wins.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    node_context_data
    
+                
    node_context_data
    
 
-
    (Label): Provides info about the build context, such as stamping.
    
+                
    (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
    
+                
    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
    
+                
    Defaults to @build_bazel_rules_nodejs//internal:node_context_data
    
 
-
    srcs
    
+                
    srcs
    
 
-
    (List of labels): Files which should be copied into the package
    
+                
    (List of labels): Files which should be copied into the package
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    substitutions
    
+                
    substitutions
    
 
-
    (Dictionary: String -> String): Key-value pairs which are replaced in all the files while building the package.
    
+                
    (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.
    
+                
    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 {}
    
+                
    Defaults to {}
    
 
-
    yarn_install
    
+                
    yarn_install
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     yarn_install(name, args, data, environment, included_files, manual_build_file_contents,
              package_json, quiet, repo_mapping, strict_visibility, symlink_node_modules, timeout,
              use_global_yarn_cache, yarn_lock)
 
    
 
-
    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.
    
-
-
    LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL
    
-
-
    When using a monorepo is common to have locally written modules that we both
-want to use locally while publicly publishing them. That is not much of a problem
-as we can use a js_library rule with a package_name attribute defined inside the
-local package BUILD file. However, if we are in the middle of transition into bazel,
-or we have any other requirement to use that local package outside bazel we will also
-have to declare and install the local package with link: in the monorepo package.json
-dependencies, which could introduce a race condition within the yarn_install rule.
    
-
-
    In order to overcome it, a link will be created to the package BUILD file from the
-npm external Bazel repository, which require us to complete a last step which is writing
-the expected targets on that same BUILD file to be later used by the yarn_install
-rule, which are: <package_name__files>, <package_name__nested_node_modules>,
-<package_name__contents>, <package_name__typings> and the last
-one just <package_name>.
    
+                
    Runs yarn install during workspace setup.
    
 
-
    If you doubt what those targets should look like, check the
-generated BUILD file for a given node module.
    
+                
    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
    
+                
    ATTRIBUTES
    
 
-
    name
    
+                
    name
    
 
-
    (Name, mandatory): A unique name for this repository.
    
+                
    (Name, mandatory): A unique name for this repository.
    
 
-
    args
    
+                
    args
    
 
-
    (List of strings): Arguments passed to yarn install.
    
+                
    (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.
    
+                
    See yarn CLI docs https://yarnpkg.com/en/docs/cli/install for complete list of supported arguments.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    data
    
+                
    data
    
 
-
    (List of labels): Data files required by this rule.
    
+                
    (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 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.
    
+                
    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 []
    
+                
    Defaults to []
    
 
-
    environment
    
+                
    environment
    
 
-
    (Dictionary: String -> String): Environment variables to set before calling the package manager.
    
+                
    (Dictionary: String -> String): Environment variables to set before calling the package manager.
    
 
-
    Defaults to {}
    
+                
    Defaults to {}
    
 
-
    included_files
    
+                
    included_files
    
 
-
    (List of strings): List of file extensions to be included in the npm package targets.
    
+                
    (List of strings): List of file extensions to be included in the npm package targets.
    
 
-
    For example, [“.js”, “.d.ts”, “.proto”, “.json”, “”].
    
+                
    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 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.
    
+                
    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.
    
+                
    This attribute applies to both the coarse @wksp//:node_modules target
+                    as well as the fine grained targets such as @wksp//foo.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    manual_build_file_contents
    
+                
    manual_build_file_contents
    
 
-
    (String): Experimental attribute that can be used to override the generated BUILD.bazel file and set its contents manually.
    
+                
    (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.
    
+                
    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 ""
    
+                
    Defaults to ""
    
 
-
    package_json
    
+                
    package_json
    
 
-
    (Label, mandatory)
    
+                
    (Label, mandatory)
    
 
-
    quiet
    
+                
    quiet
    
 
-
    (Boolean): If stdout and stderr should be printed to the terminal.
    
+                
    (Boolean): If stdout and stderr should be printed to the terminal.
    
 
-
    Defaults to True
    
+                
    Defaults to True
    
 
-
    repo_mapping
    
+                
    repo_mapping
    
 
-
    (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.<p>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).
    
+                
    (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.<p>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).
    
 
-
    strict_visibility
    
+                
    strict_visibility
    
 
-
    (Boolean): Turn on stricter visibility for generated BUILD.bazel files
    
+                
    (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.
    
+                
    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.
    
 
-
    Defaults to True
    
+                
    Defaults to True
    
 
-
+                
 
-
    (Boolean): Turn symlinking of node_modules on
    
+                
    (Boolean): Turn symlinking of node_modules on
    
 
-
    This requires the use of Bazel 0.26.0 and the experimental
-managed_directories feature.
    
+                
    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 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.
    
+                
    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
    
+                
    Defaults to True
    
 
-
    timeout
    
+                
    timeout
    
 
-
    (Integer): Maximum duration of the package manager execution in seconds.
    
+                
    (Integer): Maximum duration of the package manager execution in seconds.
    
 
-
    Defaults to 3600
    
+                
    Defaults to 3600
    
 
-
    use_global_yarn_cache
    
+                
    use_global_yarn_cache
    
 
-
    (Boolean): Use the global yarn cache on the system.
    
+                
    (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.
    
+                
    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.
    
+                
    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 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.
    
+                
    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
    
+                
    Defaults to True
    
 
-
    yarn_lock
    
+                
    yarn_lock
    
 
-
    (Label, mandatory)
    
+                
    (Label, mandatory)
    
 
-
    check_bazel_version
    
+                
    check_bazel_version
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     check_bazel_version(minimum_bazel_version, message)
 
    
 
-
    Verify the users Bazel version is at least the given one.
+                
    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 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.
    
+                
    This should not be used in users WORKSPACE files. To locally pin your
+                    Bazel version, just create the .bazelversion file in your workspace.
    
 
-
    PARAMETERS
    
+                
    PARAMETERS
    
 
-
    minimum_bazel_version
    
+                
    minimum_bazel_version
    
 
-
    a string indicating the minimum version
    
+                
    a string indicating the minimum version
    
 
-
    message
    
+                
    message
    
 
-
    optional string to print to your users, could be used to help them update
    
+                
    optional string to print to your users, could be used to help them update
    
 
-
    Defaults to ""
    
+                
    Defaults to ""
    
 
-
    copy_to_bin
    
+                
    copy_to_bin
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     copy_to_bin(name, srcs, kwargs)
 
    
 
-
    Copies a source file to bazel-bin at the same workspace-relative path.
    
+                
    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
    
+                
    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 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.
    
+                
    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
    
+                
    PARAMETERS
    
 
-
    name
    
+                
    name
    
 
-
    Name of the rule.
    
+                
    Name of the rule.
    
 
-
    srcs
    
+                
    srcs
    
 
-
    A List of Labels. File(s) to to copy.
    
+                
    A List of Labels. File(s) to to copy.
    
 
-
    kwargs
    
+                
    kwargs
    
 
-
    further keyword arguments, e.g. visibility
    
+                
    further keyword arguments, e.g. visibility
    
 
-
    generated_file_test
    
+                
    generated_file_test
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     generated_file_test(name, generated, src, substring_search, src_dbg, kwargs)
 
    
 
-
    Tests that a file generated by Bazel has identical content to a file in the workspace.
    
+                
    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.
    
+                
    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
    
+                
    PARAMETERS
    
 
-
    name
    
+                
    name
    
 
-
    Name of the rule.
    
+                
    Name of the rule.
    
 
-
    generated
    
+                
    generated
    
 
-
    a Label of the output file generated by another rule
    
+                
    a Label of the output file generated by another rule
    
 
-
    src
    
+                
    src
    
 
-
    Label of the source file in the workspace
    
+                
    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.
    
+                
    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
    
+                
    Defaults to False
    
 
-
    src_dbg
    
+                
    src_dbg
    
 
-
    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
    
+                
    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
    
+                
    Defaults to None
    
 
-
    kwargs
    
+                
    kwargs
    
 
-
    extra arguments passed to the underlying nodejs_test or nodejs_binary
    
+                
    extra arguments passed to the underlying nodejs_test or nodejs_binary
    
 
-
    js_library
    
+                
    js_library
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     js_library(name, srcs, package_name, deps, kwargs)
 
    
 
-
    Groups JavaScript code so that it can be depended on like an npm package.
    
+                
    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.
    
+                
    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.
    
-
    
+                
    
+                    
    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.
    
+                
    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
    
+                
    Example
    
 
-
    A typical example usage of js_library is to expose some sources with a package name:
    
+                
    A typical example usage of js_library is to expose some sources with a package name:
    
 
-
    ts_project(
+                
    ts_project(
     name = "compile_ts",
     srcs = glob(["*.ts"]),
 )
@@ -1598,680 +1558,680 @@ 
    Example
    
 )
 
    
 
-
    
-  
    To help work with “named AMD” modules as required by concatjs_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.
    
-
    
+                
    
+                    
    To help work with “named AMD” modules as required by concatjs_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
    
+                
    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
      • 
-
    
+                
    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.
    
+                
    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.
    
+                
    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
      • 
-
    
+                
    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
    
+                
    PARAMETERS
    
 
-
    name
    
+                
    name
    
 
-
    a name for the target
    
+                
    a name for the target
    
 
-
    srcs
    
+                
    srcs
    
 
-
    the list of files that comprise the package
    
+                
    the list of files that comprise the package
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    package_name
    
+                
    package_name
    
 
-
    the name it will be imported by. Should match the “name” field in the package.json file.
    
+                
    the name it will be imported by. Should match the “name” field in the package.json file.
    
 
-
    Defaults to None
    
+                
    Defaults to None
    
 
-
    deps
    
+                
    deps
    
 
-
    other targets that provide JavaScript code
    
+                
    other targets that provide JavaScript code
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    kwargs
    
+                
    kwargs
    
 
-
    used for undocumented legacy features
    
+                
    used for undocumented legacy features
    
 
-
    npm_package_bin
    
+                
    npm_package_bin
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     npm_package_bin(tool, package, package_bin, data, outs, args, output_dir, link_workspace_root,
                 kwargs)
 
    
 
-
    Run an arbitrary npm package binary (e.g. a program under node_modules/.bin/*) under Bazel.
    
+                
    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.
    
+                
    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.
    
+                
    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.
    
+                
    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
    
+                
    This is a great candidate to wrap with a macro, as documented:
+                    https://docs.bazel.build/versions/master/skylark/macros.html#full-example
    
 
-
    PARAMETERS
    
+                
    PARAMETERS
    
 
-
    tool
    
+                
    tool
    
 
-
    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.
    
+                
    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
    
+                
    Defaults to None
    
 
-
    package
    
+                
    package
    
 
-
    an npm package whose binary to run, like “terser”. Assumes your node_modules are installed in a workspace called “npm”
    
+                
    an npm package whose binary to run, like “terser”. Assumes your node_modules are installed in a workspace called “npm”
    
 
-
    Defaults to None
    
+                
    Defaults to None
    
 
-
    package_bin
    
+                
    package_bin
    
 
-
    the “bin” entry from package that should be run. By default package_bin is the same string as package
    
+                
    the “bin” entry from package that should be run. By default package_bin is the same string as package
    
 
-
    Defaults to None
    
+                
    Defaults to None
    
 
-
    data
    
+                
    data
    
 
-
    similar to genrule.srcs
-may also include targets that produce or reference npm packages which are needed by the tool
    
+                
    similar to genrule.srcs
+                    may also include targets that produce or reference npm packages which are needed by the tool
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    outs
    
+                
    outs
    
 
-
    similar to genrule.outs
    
+                
    similar to genrule.outs
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    args
    
+                
    args
    
 
-
    Command-line arguments to the tool.
    
+                
    Command-line arguments to the tool.
    
 
-
    Subject to ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.
    
+                
    Subject to ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.
    
 
-
      
-  
    1. Predefined source/output path substitions is applied first:
      2. 
-
    
+                
      
+                    
    1. Predefined source/output path substitions is applied first:
      2. 
+                
    
 
-
    See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_label_variables.
    
+                
    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 $(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.
    
+                
    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.
    
+                
    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.
    
+                
    Using $(location) and $(locations) expansions is not recommended as these are a synonyms
+                    for either $(execpath) or $(rootpath) depending on the context.
    
 
-
      
-  
    1. “Make” variables are expanded second:
      2. 
-
    
+                
      
+                    
    1. “Make” variables are expanded second:
      2. 
+                
    
 
-
    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 “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.
    
+                
    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)
      • 
-
    
+                
      
+                    
    • $@: 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.
    
+                
    See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_genrule_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.
    
+                
    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.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    output_dir
    
+                
    output_dir
    
 
-
    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.
    
+                
    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
    
+                
    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.
    
+                
    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
    
+                
    Defaults to False
    
 
-
    kwargs
    
+                
    kwargs
    
 
-
    params_file
    
+                
    params_file
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     params_file(name, out, args, data, newline, kwargs)
 
    
 
-
    Generates a UTF-8 encoded params file from a list of arguments.
    
+                
    Generates a UTF-8 encoded params file from a list of arguments.
    
 
-
    Handles variable substitutions for args.
    
+                
    Handles variable substitutions for args.
    
 
-
    PARAMETERS
    
+                
    PARAMETERS
    
 
-
    name
    
+                
    name
    
 
-
    Name of the rule.
    
+                
    Name of the rule.
    
 
-
    out
    
+                
    out
    
 
-
    Path of the output file, relative to this package.
    
+                
    Path of the output file, relative to this package.
    
 
-
    args
    
+                
    args
    
 
-
    Arguments to concatenate into a params file.
    
+                
    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 ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.
    
 
-
      
-  
    1. Subject to predefined source/output path variables substitutions.
      2. 
-
    
+                
      
+                    
    1. Subject to predefined source/output path variables substitutions.
      2. 
+                
    
 
-
    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.
    
+                
    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.
    
+                
    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.
    
+                
    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.
    
 
-
      
-  
    1. Subject to predefined variables & custom variable substitutions.
      2. 
-
    
+                
      
+                    
    1. Subject to predefined variables & custom variable substitutions.
      2. 
+                
    
 
-
    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 “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.
    
+                
    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.
    
+                
    Predefined genrule variables are not supported in this context.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    data
    
+                
    data
    
 
-
    Data for $(location) expansions in args.
    
+                
    Data for $(location) expansions in args.
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    newline
    
+                
    newline
    
 
-
    Line endings to use. One of [“auto”, “unix”, “windows”].
    
+                
    Line endings to use. One of [“auto”, “unix”, “windows”].
    
 
-
    “auto” for platform-determined
-“unix” for LF
-“windows” for CRLF
    
+                
    “auto” for platform-determined
+                    “unix” for LF
+                    “windows” for CRLF
    
 
-
    Defaults to "auto"
    
+                
    Defaults to "auto"
    
 
-
    kwargs
    
+                
    kwargs
    
 
-
    DeclarationInfo
    
+                
    DeclarationInfo
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     DeclarationInfo(declarations, transitive_declarations, type_blacklisted_declarations)
 
    
 
-
    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.
    
+                
    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.
    
+                
    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.
    
+                
    Note: historically this was a subset of the string-typed “typescript” provider.
    
 
-
    FIELDS
    
+                
    FIELDS
    
 
-
    declarations
    
+                
    declarations
    
 
-
    A depset of typings files produced by this rule
    
-
    transitive_declarations
    
+                
    A depset of typings files produced by this rule
    
+                
    transitive_declarations
    
 
-
    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.
    
-
    type_blacklisted_declarations
    
+                
    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.
    
+                
    type_blacklisted_declarations
    
 
-
    A depset of .d.ts files that we should not use to infer JSCompiler types (via tsickle)
    
+                
    A depset of .d.ts files that we should not use to infer JSCompiler types (via tsickle)
    
 
-
    JSEcmaScriptModuleInfo
    
+                
    JSEcmaScriptModuleInfo
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     JSEcmaScriptModuleInfo(direct_sources, sources)
 
    
 
-
    JavaScript files (and sourcemaps) that are intended to be consumed by downstream tooling.
    
+                
    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”
    
+                
    They should use modern syntax and ESModules.
+                    These files should typically be named “foo.mjs”
    
 
-
    Historical note: this was the typescript.es6_sources output
    
+                
    Historical note: this was the typescript.es6_sources output
    
 
-
    FIELDS
    
+                
    FIELDS
    
 
-
    direct_sources
    
+                
    direct_sources
    
 
-
    Depset of direct JavaScript files and sourcemaps
    
-
    sources
    
+                
    Depset of direct JavaScript files and sourcemaps
    
+                
    sources
    
 
-
    Depset of direct and transitive JavaScript files and sourcemaps
    
+                
    Depset of direct and transitive JavaScript files and sourcemaps
    
 
-
    JSModuleInfo
    
+                
    JSModuleInfo
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     JSModuleInfo(direct_sources, sources)
 
    
 
-
    JavaScript files and sourcemaps.
    
+                
    JavaScript files and sourcemaps.
    
 
-
    FIELDS
    
+                
    FIELDS
    
 
-
    direct_sources
    
+                
    direct_sources
    
 
-
    Depset of direct JavaScript files and sourcemaps
    
-
    sources
    
+                
    Depset of direct JavaScript files and sourcemaps
    
+                
    sources
    
 
-
    Depset of direct and transitive JavaScript files and sourcemaps
    
+                
    Depset of direct and transitive JavaScript files and sourcemaps
    
 
-
    JSNamedModuleInfo
    
+                
    JSNamedModuleInfo
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     JSNamedModuleInfo(direct_sources, sources)
 
    
 
-
    JavaScript files whose module name is self-contained.
    
+                
    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)
    
+                
    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.
    
+                
    Historical note: this was the typescript.es5_sources output.
    
 
-
    FIELDS
    
+                
    FIELDS
    
 
-
    direct_sources
    
+                
    direct_sources
    
 
-
    Depset of direct JavaScript files and sourcemaps
    
-
    sources
    
+                
    Depset of direct JavaScript files and sourcemaps
    
+                
    sources
    
 
-
    Depset of direct and transitive JavaScript files and sourcemaps
    
+                
    Depset of direct and transitive JavaScript files and sourcemaps
    
 
-
    LinkablePackageInfo
    
+                
    LinkablePackageInfo
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     LinkablePackageInfo(files, package_name, path, _tslibrary)
 
    
 
-
    The LinkablePackageInfo provider provides information to the linker for linking pkg_npm built packages
    
+                
    The LinkablePackageInfo provider provides information to the linker for linking pkg_npm built packages
    
 
-
    FIELDS
    
+                
    FIELDS
    
 
-
    files
    
+                
    files
    
 
-
    Depset of files in this package (must all be contained within path)
    
-
    package_name
    
+                
    Depset of files in this package (must all be contained within path)
    
+                
    package_name
    
 
-
    The package name.
    
+                
    The package name.
    
 
-
    Should be the same as name field in the package’s package.json.
    
+                
    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.
    
-
    path
    
+                
    In the future, the linker may validate that the names match the name in a package.json file.
    
+                
    path
    
 
-
    The path to link to.
    
+                
    The path to link to.
    
 
-
    Path must be relative to execroot/wksp. It can either an output dir path such as,
    
+                
    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
    
+                
    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,
    
+                
    or a source file path such as,
    
 
-
    path/to/package or
-external/<external_wksp>/path/to/package
    
-
    _tslibrary
    
+                
    path/to/package or
+                    external/<external_wksp>/path/to/package
    
+                
    _tslibrary
    
 
-
    For internal use only
    
+                
    For internal use only
    
 
-
    NodeContextInfo
    
+                
    NodeContextInfo
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     NodeContextInfo(stamp)
 
    
 
-
    Provides data about the build context, like config_setting’s
    
+                
    Provides data about the build context, like config_setting’s
    
 
-
    FIELDS
    
+                
    FIELDS
    
 
-
    stamp
    
+                
    stamp
    
 
-
    If stamping is enabled
    
+                
    If stamping is enabled
    
 
-
    NodeRuntimeDepsInfo
    
+                
    NodeRuntimeDepsInfo
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     NodeRuntimeDepsInfo(deps, pkgs)
 
    
 
-
    Stores runtime dependencies of a nodejs_binary or nodejs_test
    
+                
    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.
    
+                
    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.
    
+                
    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.
    
+                
    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
    
+                
    FIELDS
    
 
-
    deps
    
+                
    deps
    
 
-
    depset of runtime dependency labels
    
-
    pkgs
    
+                
    depset of runtime dependency labels
    
+                
    pkgs
    
 
-
    list of labels of packages that provide NpmPackageInfo
    
+                
    list of labels of packages that provide NpmPackageInfo
    
 
-
    NpmPackageInfo
    
+                
    NpmPackageInfo
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     NpmPackageInfo(direct_sources, sources, workspace)
 
    
 
-
    Provides information about npm dependencies
    
+                
    Provides information about npm dependencies
    
 
-
    FIELDS
    
+                
    FIELDS
    
 
-
    direct_sources
    
+                
    direct_sources
    
 
-
    Depset of direct source files in this npm package
    
-
    sources
    
+                
    Depset of direct source files in this npm package
    
+                
    sources
    
 
-
    Depset of direct & transitive source files in this npm package and in its dependencies
    
-
    workspace
    
+                
    Depset of direct & transitive source files in this npm package and in its dependencies
    
+                
    workspace
    
 
-
    The workspace name that this npm package is provided from
    
+                
    The workspace name that this npm package is provided from
    
 
-
    declaration_info
    
+                
    declaration_info
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     declaration_info(declarations, deps)
 
    
 
-
    Constructs a DeclarationInfo including all transitive files needed to type-check from DeclarationInfo providers in a list of deps.
    
+                
    Constructs a DeclarationInfo including all transitive files needed to type-check from DeclarationInfo providers in a list of deps.
    
 
-
    PARAMETERS
    
+                
    PARAMETERS
    
 
-
    declarations
    
+                
    declarations
    
 
-
    list of typings files
    
+                
    list of typings files
    
 
-
    deps
    
+                
    deps
    
 
-
    list of labels of dependencies where we should collect their DeclarationInfo to pass transitively
    
+                
    list of labels of dependencies where we should collect their DeclarationInfo to pass transitively
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    js_ecma_script_module_info
    
+                
    js_ecma_script_module_info
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     js_ecma_script_module_info(sources, deps)
 
    
 
-
    Constructs a JSEcmaScriptModuleInfo including all transitive sources from JSEcmaScriptModuleInfo providers in a list of deps.
    
+                
    Constructs a JSEcmaScriptModuleInfo including all transitive sources from JSEcmaScriptModuleInfo providers in a list of deps.
    
 
-
    Returns a single JSEcmaScriptModuleInfo.
    
+                
    Returns a single JSEcmaScriptModuleInfo.
    
 
-
    PARAMETERS
    
+                
    PARAMETERS
    
 
-
    sources
    
+                
    sources
    
 
-
    deps
    
+                
    deps
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    js_module_info
    
+                
    js_module_info
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     js_module_info(sources, deps)
 
    
 
-
    Constructs a JSModuleInfo including all transitive sources from JSModuleInfo providers in a list of deps.
    
+                
    Constructs a JSModuleInfo including all transitive sources from JSModuleInfo providers in a list of deps.
    
 
-
    Returns a single JSModuleInfo.
    
+                
    Returns a single JSModuleInfo.
    
 
-
    PARAMETERS
    
+                
    PARAMETERS
    
 
-
    sources
    
+                
    sources
    
 
-
    deps
    
+                
    deps
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    js_named_module_info
    
+                
    js_named_module_info
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     js_named_module_info(sources, deps)
 
    
 
-
    Constructs a JSNamedModuleInfo including all transitive sources from JSNamedModuleInfo providers in a list of deps.
    
+                
    Constructs a JSNamedModuleInfo including all transitive sources from JSNamedModuleInfo providers in a list of deps.
    
 
-
    Returns a single JSNamedModuleInfo.
    
+                
    Returns a single JSNamedModuleInfo.
    
 
-
    PARAMETERS
    
+                
    PARAMETERS
    
 
-
    sources
    
+                
    sources
    
 
-
    deps
    
+                
    deps
    
 
-
    Defaults to []
    
+                
    Defaults to []
    
 
-
    run_node
    
+                
    run_node
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     run_node(ctx, inputs, arguments, executable, kwargs)
 
    
 
-
    Helper to replace ctx.actions.run
    
+                
    Helper to replace ctx.actions.run
    
 
-
    This calls node programs with a node_modules directory in place
    
+                
    This calls node programs with a node_modules directory in place
    
 
-
    PARAMETERS
    
+                
    PARAMETERS
    
 
-
    ctx
    
+                
    ctx
    
 
-
    rule context from the calling rule implementation function
    
+                
    rule context from the calling rule implementation function
    
 
-
    inputs
    
+                
    inputs
    
 
-
    list or depset of inputs to the action
    
+                
    list or depset of inputs to the action
    
 
-
    arguments
    
+                
    arguments
    
 
-
    list or ctx.actions.Args object containing arguments to pass to the executable
    
+                
    list or ctx.actions.Args object containing arguments to pass to the executable
    
 
-
    executable
    
+                
    executable
    
 
-
    stringy representation of the executable this action will run, eg eg. “my_executable” rather than ctx.executable.my_executable
    
+                
    stringy representation of the executable this action will run, eg eg. “my_executable” rather than ctx.executable.my_executable
    
 
-
    kwargs
    
+                
    kwargs
    
 
-
    node_modules_aspect
    
+                
    node_modules_aspect
    
 
-
    USAGE
    
+                
    USAGE
    
 
-
    +                
     node_modules_aspect(name)
 
    
 
-
    ASPECT ATTRIBUTES
    
+                
    ASPECT ATTRIBUTES
    
 
-
    deps
    
+                
    deps
    
 
-
    ATTRIBUTES
    
+                
    ATTRIBUTES
    
 
-
    name
    
+                
    name
    
 
-
    (Name, {util.mandatoryString(name: “name”
+                
    (Name, {util.mandatoryString(name: “name”
 doc_string: “A unique name for this target.”
 type: NAME
 mandatory: true
 )})
- A unique name for this target.
    
+                    A unique name for this target.
    
 
 
-      
    
-    
    
+            
    
+        
    
 
-    
    
-      
    
-        
-        
-      
    
+        
    
+            
    
+                
+                
+            
    
+        
    
     
    
-  
    
 
    
 
 
    
-  
    
-  
    
-    
    
-      
    © 2020 The rules_nodejs authors
    
+    
    
+        
    
+            
    
+                
    © 2020 The rules_nodejs authors
    
+            
    
+        
    
     
    
-  
    
-
    
 
 
    
 
@@ -2285,63 +2245,62 @@ 
    name
    
 
 
 
 
 
 
 
 
-
diff --git a/docs/Built-ins.md b/docs/Built-ins.md
index f52aa50e62..62c379affa 100755
--- a/docs/Built-ins.md
+++ b/docs/Built-ins.md
@@ -833,27 +833,6 @@ This rule will set the environment variable `BAZEL_NPM_INSTALL` to '1' (unless i
 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.
 
-
-**LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL**
-
-When using a monorepo is common to have locally written modules that we both
-want to use locally while publicly publishing them. That is not much of a problem
-as we can use a `js_library` rule with a `package_name` attribute defined inside the
-local package `BUILD` file. However, if we are in the middle of transition into bazel,
-or we have any other requirement to use that local package outside bazel we will also
-have to declare and install the local package with `file:` in the monorepo `package.json`
-dependencies, which could introduce a race condition within the `npm_install rule`.
-
-In order to overcome it, a link will be created to the package `BUILD` file from the
-npm external Bazel repository, which require us to complete a last step which is writing
-the expected targets on that same `BUILD` file to be later used by the `npm_install`
-rule, which are: ``, ``,
-``, `` and the last
-one just ``.
-
-If you doubt what those targets should look like, check the
-generated `BUILD` file for a given node module.
-
 **ATTRIBUTES**
 
 
@@ -1189,27 +1168,6 @@ This rule will set the environment variable `BAZEL_YARN_INSTALL` to '1' (unless
 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.
 
-
-**LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL**
-
-When using a monorepo is common to have locally written modules that we both
-want to use locally while publicly publishing them. That is not much of a problem
-as we can use a `js_library` rule with a `package_name` attribute defined inside the
-local package `BUILD` file. However, if we are in the middle of transition into bazel,
-or we have any other requirement to use that local package outside bazel we will also
-have to declare and install the local package with `link:` in the monorepo `package.json`
-dependencies, which could introduce a race condition within the `yarn_install rule`.
-
-In order to overcome it, a link will be created to the package `BUILD` file from the
-npm external Bazel repository, which require us to complete a last step which is writing
-the expected targets on that same `BUILD` file to be later used by the `yarn_install`
-rule, which are: ``, ``,
-``, `` and the last
-one just ``.
-
-If you doubt what those targets should look like, check the
-generated `BUILD` file for a given node module.
-
 **ATTRIBUTES**
 
 
@@ -2225,4 +2183,3 @@ mandatory: true
  A unique name for this target. 
 
 
-

From 1646661af6f740e38e6ceee1cd0bdb53791b5829 Mon Sep 17 00:00:00 2001
From: Tiago Costa 
Date: Wed, 16 Dec 2020 05:27:52 +0000
Subject: [PATCH 4/9] docs(builtin): restore old source for builtin doc
 generated files

---
 docs/Built-ins.html | 2577 ++++++++++++++++++++++---------------------
 docs/Built-ins.md   |    1 +
 2 files changed, 1290 insertions(+), 1288 deletions(-)

diff --git a/docs/Built-ins.html b/docs/Built-ins.html
index 5f0397209d..87c90eed1c 100755
--- a/docs/Built-ins.html
+++ b/docs/Built-ins.html
@@ -1,212 +1,212 @@
 
 
 
-    
-    
-    
-    
-    
+  
+  
+  
+  
+  
 
-    rules_nodejs - Built-ins
+  rules_nodejs - Built-ins
 
-    
-    
+  
+  
 
-    
-    
+  
+  
 
-    
-    
+  
+  
 
-    
-    
-    
+  
+  
+  
 
-    
-    
+  
+  
 
-    
-    
-    
+  
+  
+  
 
 
 
 
 
 
 
    
-    
    
-        
    
-            
-
-            
-        
    
+  
    
+    
    
+  
+
+  
+
    
 
 
-        
    
-            
    
-                
-                
    Built-in rules
    
+    
    
+      
    
+        
+
    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.
    
+
    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
    
+
    node_repositories
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     node_repositories(name, node_download_auth, node_repositories, node_urls, node_version,
                   package_json, preserve_symlinks, repo_mapping, vendored_node, vendored_yarn,
                   yarn_download_auth, yarn_repositories, yarn_urls, yarn_version)
 
    
 
-                
    To be run in user’s WORKSPACE to install rules_nodejs dependencies.
    
+
    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
    
+
    This rule sets up node, npm, and yarn. The versions of these tools can be specified in one of three ways
    
 
-                
    Simplest Usage
    
+
    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.
    
+
    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)
    
+
    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)
    
+
    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
    
+
    Using a custom version
    
 
-                
    You can pass in a custom list of NodeJS and/or Yarn repositories and URLs for node_resositories to use.
    
+
    You can pass in a custom list of NodeJS and/or Yarn repositories and URLs for node_resositories to use.
    
 
-                
    Custom NodeJS versions
    
+
    Custom NodeJS versions
    
 
-                
    To specify custom NodeJS versions, use the node_repositories attribute
    
+
    To specify custom NodeJS versions, use the node_repositories attribute
    
 
-                
    node_repositories(
+
    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"),
@@ -215,32 +215,32 @@ 
    Custom NodeJS versions
    
 )
 
    
 
-                
    These can be mapped to a custom download URL, using node_urls
    
+
    These can be mapped to a custom download URL, using node_urls
    
 
-                
    node_repositories(
+
    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
    
+
    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
    
+
    Custom Yarn versions
    
 
-                
    To specify custom Yarn versions, use the yarn_repositories attribute
    
+
    To specify custom Yarn versions, use the yarn_repositories attribute
    
 
-                
    node_repositories(
+
    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
    
+
    Like node_urls, the yarn_urls attribute can be used to provide a list of custom URLs to use to download yarn
    
 
-                
    node_repositories(
+
    node_repositories(
     yarn_repositories = {
         "1.12.1": ("yarn-v1.12.1.tar.gz", "yarn-v1.12.1", "09bea8f4ec41e9079fa03093d3b2db7ac5c5331852236d63815f8df42b3ba88d"),
     },
@@ -251,210 +251,210 @@ 
    Custom Yarn versions
    
 )
 
    
 
-                
    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.
    
+
    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
    
+
    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.
    
+
    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.
    
+
    See the the repositories documentation for how to use the resulting repositories.
    
 
-                
    Manual install
    
+
    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.
    
+
    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")
+
    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.
    
+
    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.
    
+
    Note that the dependency installation scripts will run in each subpackage indicated by the package_json attribute.
    
 
-                
    ATTRIBUTES
    
+
    ATTRIBUTES
    
 
-                
    name
    
+
    name
    
 
-                
    (Name, mandatory): A unique name for this repository.
    
+
    (Name, mandatory): A unique name for this repository.
    
 
-                
    node_download_auth
    
+
    node_download_auth
    
 
-                
    (Dictionary: String -> String): auth to use for all url requests
-                    Example: {“type”: “basic”, “login”: “", "password": "" }
    
+
    (Dictionary: String -> String): auth to use for all url requests
+Example: {“type”: “basic”, “login”: “", "password": "" }
    
 
-                
    Defaults to {}
    
+
    Defaults to {}
    
 
-                
    node_repositories
    
+
    node_repositories
    
 
-                
    (Dictionary: String -> List of strings): Custom list of node repositories to use
    
+
    (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.
    
+
    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.
    
+
    By default, if this attribute has no items, we’ll use a list of all public NodeJS releases.
    
 
-                
    Defaults to {}
    
+
    Defaults to {}
    
 
-                
    node_urls
    
+
    node_urls
    
 
-                
    (List of strings): custom list of URLs to use to download NodeJS
    
+
    (List of strings): custom list of URLs to use to download NodeJS
    
 
-                
    Each entry is a template for downloading a node distribution.
    
+
    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.
    
+
    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}"]
    
+
    Defaults to ["https://mirror.bazel.build/nodejs.org/dist/v{version}/{filename}", "https://nodejs.org/dist/v{version}/{filename}"]
    
 
-                
    node_version
    
+
    node_version
    
 
-                
    (String): the specific version of NodeJS to install or, if vendored_node is specified, the vendored version of node
    
+
    (String): the specific version of NodeJS to install or, if vendored_node is specified, the vendored version of node
    
 
-                
    Defaults to "12.13.0"
    
+
    Defaults to "12.13.0"
    
 
-                
    package_json
    
+
    package_json
    
 
-                
    (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.
    
+
    (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 []
    
+
    Defaults to []
    
 
-                
+
 
-                
    (Boolean): Turn on –node_options=–preserve-symlinks for nodejs_binary and nodejs_test rules.
    
+
    (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.
    
+
    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
    
+
    Defaults to True
    
 
-                
    repo_mapping
    
+
    repo_mapping
    
 
-                
    (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.<p>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).
    
+
    (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.<p>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).
    
 
-                
    vendored_node
    
+
    vendored_node
    
 
-                
    (Label): the local path to a pre-installed NodeJS runtime.
    
+
    (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.
    
+
    If set then also set node_version to the version that of node that is vendored.
    
 
-                
    Defaults to None
    
+
    Defaults to None
    
 
-                
    vendored_yarn
    
+
    vendored_yarn
    
 
-                
    (Label): the local path to a pre-installed yarn tool
    
+
    (Label): the local path to a pre-installed yarn tool
    
 
-                
    Defaults to None
    
+
    Defaults to None
    
 
-                
    yarn_download_auth
    
+
    yarn_download_auth
    
 
-                
    (Dictionary: String -> String): auth to use for all url requests
-                    Example: {“type”: “basic”, “login”: “", "password": "" }
    
+
    (Dictionary: String -> String): auth to use for all url requests
+Example: {“type”: “basic”, “login”: “", "password": "" }
    
 
-                
    Defaults to {}
    
+
    Defaults to {}
    
 
-                
    yarn_repositories
    
+
    yarn_repositories
    
 
-                
    (Dictionary: String -> List of strings): Custom list of yarn repositories to use.
    
+
    (Dictionary: String -> List of strings): Custom list of yarn repositories to use.
    
 
-                
    Dictionary mapping Yarn versions to their corresponding (filename, strip_prefix, sha256) tuples.
    
+
    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.
    
+
    By default, if this attribute has no items, we’ll use a list of all public NodeJS releases.
    
 
-                
    Defaults to {}
    
+
    Defaults to {}
    
 
-                
    yarn_urls
    
+
    yarn_urls
    
 
-                
    (List of strings): custom list of URLs to use to download Yarn
    
+
    (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.
    
+
    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}"]
    
+
    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}"]
    
 
-                
    yarn_version
    
+
    yarn_version
    
 
-                
    (String): the specific version of Yarn to install
    
+
    (String): the specific version of Yarn to install
    
 
-                
    Defaults to "1.19.1"
    
+
    Defaults to "1.19.1"
    
 
-                
    nodejs_binary
    
+
    nodejs_binary
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     nodejs_binary(name, configuration_env_vars, data, default_env_vars, entry_point,
               link_workspace_root, node_modules, templated_args)
 
    
 
-                
    Runs some JavaScript code in NodeJS.
    
+
    Runs some JavaScript code in NodeJS.
    
 
-                
    ATTRIBUTES
    
+
    ATTRIBUTES
    
 
-                
    name
    
+
    name
    
 
-                
    (Name, mandatory): A unique name for this target.
    
+
    (Name, mandatory): A unique name for this target.
    
 
-                
    configuration_env_vars
    
+
    configuration_env_vars
    
 
-                
    (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.
    
+
    (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 []
    
+
    Defaults to []
    
 
-                
    data
    
+
    data
    
 
-                
    (List of labels): Runtime dependencies which may be loaded during execution.
    
+
    (List of labels): Runtime dependencies which may be loaded during execution.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    default_env_vars
    
+
    default_env_vars
    
 
-                
    (List of strings): Default environment variables that are added to configuration_env_vars.
    
+
    (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.
    
+
    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:
    
+
    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
      • 
-                
    
+
      
+  
    • 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"]
    
+
    Defaults to ["VERBOSE_LOGS", "NODE_DEBUG", "RUNFILES_LIB_DEBUG"]
    
 
-                
    entry_point
    
+
    entry_point
    
 
-                
    (Label, mandatory): The script which should be executed first, usually containing a main function.
    
+
    (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:
    
+
    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(
+
    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:
    
+
    You can specify the entry point as a typescript file so long as you also include
+the ts_library target in data:
    
 
-                
    ts_library(
+
    ts_library(
     name = "main",
     srcs = ["main.ts"],
 )
@@ -466,12 +466,12 @@ 
    entry_point
    
 )
 
    
 
-                
    The rule will use the corresponding .js output of the ts_library rule as the entry point.
    
+
    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:
    
+
    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(
+
    filegroup(
     name = "entry_file",
     srcs = ["main.js"],
 )
@@ -482,45 +482,45 @@ 
    entry_point
    
 )
 
    
 
-                
    The entry_point can also be a label in another workspace:
    
+
    The entry_point can also be a label in another workspace:
    
 
-                
    nodejs_binary(
+
    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.
    
+
    (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
    
+
    Defaults to False
    
 
-                
    node_modules
    
+
    node_modules
    
 
-                
    (Label): The npm packages which should be available to require() during
-                    execution.
    
+
    (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,
    
+
    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(
+
    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:
    
+
    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(
+
    nodejs_binary(
     name = "my_binary",
     ...
     data = [
@@ -531,25 +531,25 @@ 
    node_modules
    
 )
 
    
 
-                
    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).
    
+
    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:
    
+
    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”,
-                    )
    
+
    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:
    
+
    For other rules such as jasmine_node_test, fine grained
+npm dependencies are specified in the deps attribute:
    
 
-                
    jasmine_node_test(
+
    jasmine_node_test(
     name = "my_test",
     ...
     deps = [
@@ -561,48 +561,48 @@ 
    node_modules
    
 )
 
    
 
-                
    Defaults to //:node_modules_none
    
+
    Defaults to //:node_modules_none
    
 
-                
    templated_args
    
+
    templated_args
    
 
-                
    (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.
    
+
    (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 ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.
    
 
-                
      
-                    
    1. Subject to predefined source/output path variables substitutions.
      2. 
-                
    
+
      
+  
    1. Subject to predefined source/output path variables substitutions.
      2. 
+
    
 
-                
    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.
    
+
    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.
    
+
    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.
    
+
    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).
    
+
    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:
    
+
    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(
+
    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:
    
+
    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(
+
    BUILD.bazel:
    
+
    nodejs_test(
     name = "my_test",
     data = [":some_file"],
     entry_point = ":my_test.js",
@@ -610,134 +610,134 @@ 
    templated_args
    
 )
 
    
 
-                
    my_test.js
    
-                
    const runfiles = require(process.env['BAZEL_NODE_RUNFILES_HELPER']);
+
    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.
    
+
    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.
    
+
    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.
    
+
    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.
    
 
-                
      
-                    
    1. Subject to predefined variables & custom variable substitutions.
      2. 
-                
    
+
      
+  
    1. Subject to predefined variables & custom variable substitutions.
      2. 
+
    
 
-                
    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 “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.
    
+
    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.
    
+
    Predefined genrule variables are not supported in this context.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    nodejs_test
    
+
    nodejs_test
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     nodejs_test(name, configuration_env_vars, data, default_env_vars, entry_point, expected_exit_code,
             link_workspace_root, node_modules, templated_args)
 
    
 
-                
    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.
    
+
    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
    
+
    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.
    
+
    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.
    
+
    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
+
    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.
    
+
    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
    
+
    ATTRIBUTES
    
 
-                
    name
    
+
    name
    
 
-                
    (Name, mandatory): A unique name for this target.
    
+
    (Name, mandatory): A unique name for this target.
    
 
-                
    configuration_env_vars
    
+
    configuration_env_vars
    
 
-                
    (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.
    
+
    (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 []
    
+
    Defaults to []
    
 
-                
    data
    
+
    data
    
 
-                
    (List of labels): Runtime dependencies which may be loaded during execution.
    
+
    (List of labels): Runtime dependencies which may be loaded during execution.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    default_env_vars
    
+
    default_env_vars
    
 
-                
    (List of strings): Default environment variables that are added to configuration_env_vars.
    
+
    (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.
    
+
    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:
    
+
    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
      • 
-                
    
+
      
+  
    • 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"]
    
+
    Defaults to ["VERBOSE_LOGS", "NODE_DEBUG", "RUNFILES_LIB_DEBUG"]
    
 
-                
    entry_point
    
+
    entry_point
    
 
-                
    (Label, mandatory): The script which should be executed first, usually containing a main function.
    
+
    (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:
    
+
    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(
+
    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:
    
+
    You can specify the entry point as a typescript file so long as you also include
+the ts_library target in data:
    
 
-                
    ts_library(
+
    ts_library(
     name = "main",
     srcs = ["main.ts"],
 )
@@ -749,12 +749,12 @@ 
    entry_point
    
 )
 
    
 
-                
    The rule will use the corresponding .js output of the ts_library rule as the entry point.
    
+
    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:
    
+
    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(
+
    filegroup(
     name = "entry_file",
     srcs = ["main.js"],
 )
@@ -765,51 +765,51 @@ 
    entry_point
    
 )
 
    
 
-                
    The entry_point can also be a label in another workspace:
    
+
    The entry_point can also be a label in another workspace:
    
 
-                
    nodejs_binary(
+
    nodejs_binary(
     name = "history-server",
     entry_point = "@npm//:node_modules/history-server/modules/cli.js",
     data = ["@npm//history-server"],
 )
 
    
 
-                
    expected_exit_code
    
+
    expected_exit_code
    
 
-                
    (Integer): The expected exit code for the test. Defaults to 0.
    
+
    (Integer): The expected exit code for the test. Defaults to 0.
    
 
-                
    Defaults to 0
    
+
    Defaults to 0
    
 
-                
+
 
-                
    (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.
    
+
    (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
    
+
    Defaults to False
    
 
-                
    node_modules
    
+
    node_modules
    
 
-                
    (Label): The npm packages which should be available to require() during
-                    execution.
    
+
    (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,
    
+
    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(
+
    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:
    
+
    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(
+
    nodejs_binary(
     name = "my_binary",
     ...
     data = [
@@ -820,25 +820,25 @@ 
    node_modules
    
 )
 
    
 
-                
    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).
    
+
    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:
    
+
    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”,
-                    )
    
+
    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:
    
+
    For other rules such as jasmine_node_test, fine grained
+npm dependencies are specified in the deps attribute:
    
 
-                
    jasmine_node_test(
+
    jasmine_node_test(
     name = "my_test",
     ...
     deps = [
@@ -850,48 +850,48 @@ 
    node_modules
    
 )
 
    
 
-                
    Defaults to //:node_modules_none
    
+
    Defaults to //:node_modules_none
    
 
-                
    templated_args
    
+
    templated_args
    
 
-                
    (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.
    
+
    (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 ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.
    
 
-                
      
-                    
    1. Subject to predefined source/output path variables substitutions.
      2. 
-                
    
+
      
+  
    1. Subject to predefined source/output path variables substitutions.
      2. 
+
    
 
-                
    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.
    
+
    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.
    
+
    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.
    
+
    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).
    
+
    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:
    
+
    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(
+
    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:
    
+
    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(
+
    BUILD.bazel:
    
+
    nodejs_test(
     name = "my_test",
     data = [":some_file"],
     entry_point = ":my_test.js",
@@ -899,191 +899,191 @@ 
    templated_args
    
 )
 
    
 
-                
    my_test.js
    
-                
    const runfiles = require(process.env['BAZEL_NODE_RUNFILES_HELPER']);
+
    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.
    
+
    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.
    
+
    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.
    
+
    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.
    
 
-                
      
-                    
    1. Subject to predefined variables & custom variable substitutions.
      2. 
-                
    
+
      
+  
    1. Subject to predefined variables & custom variable substitutions.
      2. 
+
    
 
-                
    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 “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.
    
+
    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.
    
+
    Predefined genrule variables are not supported in this context.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    npm_install
    
+
    npm_install
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     npm_install(name, args, data, environment, included_files, manual_build_file_contents, package_json,
             package_lock_json, quiet, repo_mapping, strict_visibility, symlink_node_modules, timeout)
 
    
 
-                
    Runs npm install during workspace setup.
    
+
    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.
    
+
    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
    
+
    ATTRIBUTES
    
 
-                
    name
    
+
    name
    
 
-                
    (Name, mandatory): A unique name for this repository.
    
+
    (Name, mandatory): A unique name for this repository.
    
 
-                
    args
    
+
    args
    
 
-                
    (List of strings): Arguments passed to npm install.
    
+
    (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.
    
+
    See npm CLI docs https://docs.npmjs.com/cli/install.html for complete list of supported arguments.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    data
    
+
    data
    
 
-                
    (List of labels): Data files required by this rule.
    
+
    (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 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.
    
+
    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 []
    
+
    Defaults to []
    
 
-                
    environment
    
+
    environment
    
 
-                
    (Dictionary: String -> String): Environment variables to set before calling the package manager.
    
+
    (Dictionary: String -> String): Environment variables to set before calling the package manager.
    
 
-                
    Defaults to {}
    
+
    Defaults to {}
    
 
-                
    included_files
    
+
    included_files
    
 
-                
    (List of strings): List of file extensions to be included in the npm package targets.
    
+
    (List of strings): List of file extensions to be included in the npm package targets.
    
 
-                
    For example, [“.js”, “.d.ts”, “.proto”, “.json”, “”].
    
+
    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 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.
    
+
    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.
    
+
    This attribute applies to both the coarse @wksp//:node_modules target
+as well as the fine grained targets such as @wksp//foo.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    manual_build_file_contents
    
+
    manual_build_file_contents
    
 
-                
    (String): Experimental attribute that can be used to override the generated BUILD.bazel file and set its contents manually.
    
+
    (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.
    
+
    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 ""
    
+
    Defaults to ""
    
 
-                
    package_json
    
+
    package_json
    
 
-                
    (Label, mandatory)
    
+
    (Label, mandatory)
    
 
-                
    package_lock_json
    
+
    package_lock_json
    
 
-                
    (Label, mandatory)
    
+
    (Label, mandatory)
    
 
-                
    quiet
    
+
    quiet
    
 
-                
    (Boolean): If stdout and stderr should be printed to the terminal.
    
+
    (Boolean): If stdout and stderr should be printed to the terminal.
    
 
-                
    Defaults to True
    
+
    Defaults to True
    
 
-                
    repo_mapping
    
+
    repo_mapping
    
 
-                
    (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.<p>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).
    
+
    (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.<p>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).
    
 
-                
    strict_visibility
    
+
    strict_visibility
    
 
-                
    (Boolean): Turn on stricter visibility for generated BUILD.bazel files
    
+
    (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.
    
+
    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.
    
 
-                
    Defaults to True
    
+
    Defaults to True
    
 
-                
+
 
-                
    (Boolean): Turn symlinking of node_modules on
    
+
    (Boolean): Turn symlinking of node_modules on
    
 
-                
    This requires the use of Bazel 0.26.0 and the experimental
-                    managed_directories feature.
    
+
    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 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.
    
+
    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
    
+
    Defaults to True
    
 
-                
    timeout
    
+
    timeout
    
 
-                
    (Integer): Maximum duration of the package manager execution in seconds.
    
+
    (Integer): Maximum duration of the package manager execution in seconds.
    
 
-                
    Defaults to 3600
    
+
    Defaults to 3600
    
 
-                
    pkg_npm
    
+
    pkg_npm
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     pkg_npm(name, deps, nested_packages, node_context_data, package_name, srcs, substitutions,
         vendor_external)
 
    
 
-                
    The pkg_npm rule creates a directory containing a publishable npm artifact.
    
+
    The pkg_npm rule creates a directory containing a publishable npm artifact.
    
 
-                
    Example:
    
+
    Example:
    
 
-                
    load("@build_bazel_rules_nodejs//:index.bzl", "pkg_npm")
+
    load("@build_bazel_rules_nodejs//:index.bzl", "pkg_npm")
 
 pkg_npm(
     name = "my_package",
@@ -1093,10 +1093,10 @@ 
    pkg_npm
    
 )
 
    
 
-                
    You can use a pair of // BEGIN-INTERNAL ... // END-INTERNAL comments to mark regions of files that should be elided during publishing.
-                    For example:
    
+
    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() {
+
    function doThing() {
     // BEGIN-INTERNAL
     // This is a secret internal-only comment
     doInternalOnlyThing();
@@ -1104,445 +1104,445 @@ 
    pkg_npm
    
 }
 
    
 
-                
    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
    
+
    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:
    
+
    Usage:
    
 
-                
    pkg_npm yields three labels. Build the package directory using the default label:
    
+
    pkg_npm yields three labels. Build the package directory using the default label:
    
 
-                
    $ bazel build :my_package
+
    $ 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):
    
+
    Dry-run of publishing to npm, calling npm pack (it builds the package first if needed):
    
 
-                
    $ bazel run :my_package.pack
+
    $ 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):
    
+
    Actually publish the package with npm publish (also builds first):
    
 
-                
    # Check login credentials
+
    # 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:
    
+
    You can pass arguments to npm by escaping them from Bazel using a double-hyphen, for example:
    
 
-                
    bazel run my_package.publish -- --tag=next
    
+
    bazel run my_package.publish -- --tag=next
    
 
-                
    ATTRIBUTES
    
+
    ATTRIBUTES
    
 
-                
    name
    
+
    name
    
 
-                
    (Name, mandatory): A unique name for this target.
    
+
    (Name, mandatory): A unique name for this target.
    
 
-                
    deps
    
+
    deps
    
 
-                
    (List of labels): Other targets which produce files that should be included in the package, such as rollup_bundle
    
+
    (List of labels): Other targets which produce files that should be included in the package, such as rollup_bundle
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    nested_packages
    
+
    nested_packages
    
 
-                
    (List of labels): Other pkg_npm rules whose content is copied into this package.
    
+
    (List of labels): Other pkg_npm rules whose content is copied into this package.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    node_context_data
    
+
    node_context_data
    
 
-                
    (Label): Provides info about the build context, such as stamping.
    
+
    (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
    
+
    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
    
+
    Defaults to @build_bazel_rules_nodejs//internal:node_context_data
    
 
-                
    package_name
    
+
    package_name
    
 
-                
    (String): Optional package_name that this npm package may be imported as.
    
+
    (String): Optional package_name that this npm package may be imported as.
    
 
-                
    Defaults to ""
    
+
    Defaults to ""
    
 
-                
    srcs
    
+
    srcs
    
 
-                
    (List of labels): Files inside this directory which are simply copied into the package.
    
+
    (List of labels): Files inside this directory which are simply copied into the package.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    substitutions
    
+
    substitutions
    
 
-                
    (Dictionary: String -> String): Key-value pairs which are replaced in all the files while building the package.
    
+
    (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}"}.
    
+
    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
    
+
    See the section on stamping in the README
    
 
-                
    Defaults to {}
    
+
    Defaults to {}
    
 
-                
    vendor_external
    
+
    vendor_external
    
 
-                
    (List of strings): External workspaces whose contents should be vendored into this workspace.
-                    Avoids external/foo path segments in the resulting package.
    
+
    (List of strings): External workspaces whose contents should be vendored into this workspace.
+        Avoids external/foo path segments in the resulting package.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    pkg_web
    
+
    pkg_web
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     pkg_web(name, additional_root_paths, node_context_data, srcs, substitutions)
 
    
 
-                
    Assembles a web application from source files.
    
+
    Assembles a web application from source files.
    
 
-                
    ATTRIBUTES
    
+
    ATTRIBUTES
    
 
-                
    name
    
+
    name
    
 
-                
    (Name, mandatory): A unique name for this target.
    
+
    (Name, mandatory): A unique name for this target.
    
 
-                
    additional_root_paths
    
+
    additional_root_paths
    
 
-                
    (List of strings): Path prefixes to strip off all srcs, in addition to the current package. Longest wins.
    
+
    (List of strings): Path prefixes to strip off all srcs, in addition to the current package. Longest wins.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    node_context_data
    
+
    node_context_data
    
 
-                
    (Label): Provides info about the build context, such as stamping.
    
+
    (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
    
+
    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
    
+
    Defaults to @build_bazel_rules_nodejs//internal:node_context_data
    
 
-                
    srcs
    
+
    srcs
    
 
-                
    (List of labels): Files which should be copied into the package
    
+
    (List of labels): Files which should be copied into the package
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    substitutions
    
+
    substitutions
    
 
-                
    (Dictionary: String -> String): Key-value pairs which are replaced in all the files while building the package.
    
+
    (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.
    
+
    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 {}
    
+
    Defaults to {}
    
 
-                
    yarn_install
    
+
    yarn_install
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     yarn_install(name, args, data, environment, included_files, manual_build_file_contents,
              package_json, quiet, repo_mapping, strict_visibility, symlink_node_modules, timeout,
              use_global_yarn_cache, yarn_lock)
 
    
 
-                
    Runs yarn install during workspace setup.
    
+
    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.
    
+
    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
    
+
    ATTRIBUTES
    
 
-                
    name
    
+
    name
    
 
-                
    (Name, mandatory): A unique name for this repository.
    
+
    (Name, mandatory): A unique name for this repository.
    
 
-                
    args
    
+
    args
    
 
-                
    (List of strings): Arguments passed to yarn install.
    
+
    (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.
    
+
    See yarn CLI docs https://yarnpkg.com/en/docs/cli/install for complete list of supported arguments.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    data
    
+
    data
    
 
-                
    (List of labels): Data files required by this rule.
    
+
    (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 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.
    
+
    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 []
    
+
    Defaults to []
    
 
-                
    environment
    
+
    environment
    
 
-                
    (Dictionary: String -> String): Environment variables to set before calling the package manager.
    
+
    (Dictionary: String -> String): Environment variables to set before calling the package manager.
    
 
-                
    Defaults to {}
    
+
    Defaults to {}
    
 
-                
    included_files
    
+
    included_files
    
 
-                
    (List of strings): List of file extensions to be included in the npm package targets.
    
+
    (List of strings): List of file extensions to be included in the npm package targets.
    
 
-                
    For example, [“.js”, “.d.ts”, “.proto”, “.json”, “”].
    
+
    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 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.
    
+
    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.
    
+
    This attribute applies to both the coarse @wksp//:node_modules target
+as well as the fine grained targets such as @wksp//foo.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    manual_build_file_contents
    
+
    manual_build_file_contents
    
 
-                
    (String): Experimental attribute that can be used to override the generated BUILD.bazel file and set its contents manually.
    
+
    (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.
    
+
    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 ""
    
+
    Defaults to ""
    
 
-                
    package_json
    
+
    package_json
    
 
-                
    (Label, mandatory)
    
+
    (Label, mandatory)
    
 
-                
    quiet
    
+
    quiet
    
 
-                
    (Boolean): If stdout and stderr should be printed to the terminal.
    
+
    (Boolean): If stdout and stderr should be printed to the terminal.
    
 
-                
    Defaults to True
    
+
    Defaults to True
    
 
-                
    repo_mapping
    
+
    repo_mapping
    
 
-                
    (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.<p>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).
    
+
    (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.<p>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).
    
 
-                
    strict_visibility
    
+
    strict_visibility
    
 
-                
    (Boolean): Turn on stricter visibility for generated BUILD.bazel files
    
+
    (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.
    
+
    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.
    
 
-                
    Defaults to True
    
+
    Defaults to True
    
 
-                
+
 
-                
    (Boolean): Turn symlinking of node_modules on
    
+
    (Boolean): Turn symlinking of node_modules on
    
 
-                
    This requires the use of Bazel 0.26.0 and the experimental
-                    managed_directories feature.
    
+
    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 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.
    
+
    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
    
+
    Defaults to True
    
 
-                
    timeout
    
+
    timeout
    
 
-                
    (Integer): Maximum duration of the package manager execution in seconds.
    
+
    (Integer): Maximum duration of the package manager execution in seconds.
    
 
-                
    Defaults to 3600
    
+
    Defaults to 3600
    
 
-                
    use_global_yarn_cache
    
+
    use_global_yarn_cache
    
 
-                
    (Boolean): Use the global yarn cache on the system.
    
+
    (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.
    
+
    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.
    
+
    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 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.
    
+
    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
    
+
    Defaults to True
    
 
-                
    yarn_lock
    
+
    yarn_lock
    
 
-                
    (Label, mandatory)
    
+
    (Label, mandatory)
    
 
-                
    check_bazel_version
    
+
    check_bazel_version
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     check_bazel_version(minimum_bazel_version, message)
 
    
 
-                
    Verify the users Bazel version is at least the given one.
+
    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 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.
    
+
    This should not be used in users WORKSPACE files. To locally pin your
+Bazel version, just create the .bazelversion file in your workspace.
    
 
-                
    PARAMETERS
    
+
    PARAMETERS
    
 
-                
    minimum_bazel_version
    
+
    minimum_bazel_version
    
 
-                
    a string indicating the minimum version
    
+
    a string indicating the minimum version
    
 
-                
    message
    
+
    message
    
 
-                
    optional string to print to your users, could be used to help them update
    
+
    optional string to print to your users, could be used to help them update
    
 
-                
    Defaults to ""
    
+
    Defaults to ""
    
 
-                
    copy_to_bin
    
+
    copy_to_bin
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     copy_to_bin(name, srcs, kwargs)
 
    
 
-                
    Copies a source file to bazel-bin at the same workspace-relative path.
    
+
    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
    
+
    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 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.
    
+
    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
    
+
    PARAMETERS
    
 
-                
    name
    
+
    name
    
 
-                
    Name of the rule.
    
+
    Name of the rule.
    
 
-                
    srcs
    
+
    srcs
    
 
-                
    A List of Labels. File(s) to to copy.
    
+
    A List of Labels. File(s) to to copy.
    
 
-                
    kwargs
    
+
    kwargs
    
 
-                
    further keyword arguments, e.g. visibility
    
+
    further keyword arguments, e.g. visibility
    
 
-                
    generated_file_test
    
+
    generated_file_test
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     generated_file_test(name, generated, src, substring_search, src_dbg, kwargs)
 
    
 
-                
    Tests that a file generated by Bazel has identical content to a file in the workspace.
    
+
    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.
    
+
    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
    
+
    PARAMETERS
    
 
-                
    name
    
+
    name
    
 
-                
    Name of the rule.
    
+
    Name of the rule.
    
 
-                
    generated
    
+
    generated
    
 
-                
    a Label of the output file generated by another rule
    
+
    a Label of the output file generated by another rule
    
 
-                
    src
    
+
    src
    
 
-                
    Label of the source file in the workspace
    
+
    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.
    
+
    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
    
+
    Defaults to False
    
 
-                
    src_dbg
    
+
    src_dbg
    
 
-                
    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
    
+
    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
    
+
    Defaults to None
    
 
-                
    kwargs
    
+
    kwargs
    
 
-                
    extra arguments passed to the underlying nodejs_test or nodejs_binary
    
+
    extra arguments passed to the underlying nodejs_test or nodejs_binary
    
 
-                
    js_library
    
+
    js_library
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     js_library(name, srcs, package_name, deps, kwargs)
 
    
 
-                
    Groups JavaScript code so that it can be depended on like an npm package.
    
+
    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.
    
+
    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.
    
-                
    
+
    
+  
    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.
    
+
    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
    
+
    Example
    
 
-                
    A typical example usage of js_library is to expose some sources with a package name:
    
+
    A typical example usage of js_library is to expose some sources with a package name:
    
 
-                
    ts_project(
+
    ts_project(
     name = "compile_ts",
     srcs = glob(["*.ts"]),
 )
@@ -1558,680 +1558,680 @@ 
    Example
    
 )
 
    
 
-                
    
-                    
    To help work with “named AMD” modules as required by concatjs_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.
    
-                
    
+
    
+  
    To help work with “named AMD” modules as required by concatjs_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
    
+
    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
      • 
-                
    
+
    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.
    
+
    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.
    
+
    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
      • 
-                
    
+
    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
    
+
    PARAMETERS
    
 
-                
    name
    
+
    name
    
 
-                
    a name for the target
    
+
    a name for the target
    
 
-                
    srcs
    
+
    srcs
    
 
-                
    the list of files that comprise the package
    
+
    the list of files that comprise the package
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    package_name
    
+
    package_name
    
 
-                
    the name it will be imported by. Should match the “name” field in the package.json file.
    
+
    the name it will be imported by. Should match the “name” field in the package.json file.
    
 
-                
    Defaults to None
    
+
    Defaults to None
    
 
-                
    deps
    
+
    deps
    
 
-                
    other targets that provide JavaScript code
    
+
    other targets that provide JavaScript code
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    kwargs
    
+
    kwargs
    
 
-                
    used for undocumented legacy features
    
+
    used for undocumented legacy features
    
 
-                
    npm_package_bin
    
+
    npm_package_bin
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     npm_package_bin(tool, package, package_bin, data, outs, args, output_dir, link_workspace_root,
                 kwargs)
 
    
 
-                
    Run an arbitrary npm package binary (e.g. a program under node_modules/.bin/*) under Bazel.
    
+
    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.
    
+
    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.
    
+
    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.
    
+
    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
    
+
    This is a great candidate to wrap with a macro, as documented:
+https://docs.bazel.build/versions/master/skylark/macros.html#full-example
    
 
-                
    PARAMETERS
    
+
    PARAMETERS
    
 
-                
    tool
    
+
    tool
    
 
-                
    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.
    
+
    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
    
+
    Defaults to None
    
 
-                
    package
    
+
    package
    
 
-                
    an npm package whose binary to run, like “terser”. Assumes your node_modules are installed in a workspace called “npm”
    
+
    an npm package whose binary to run, like “terser”. Assumes your node_modules are installed in a workspace called “npm”
    
 
-                
    Defaults to None
    
+
    Defaults to None
    
 
-                
    package_bin
    
+
    package_bin
    
 
-                
    the “bin” entry from package that should be run. By default package_bin is the same string as package
    
+
    the “bin” entry from package that should be run. By default package_bin is the same string as package
    
 
-                
    Defaults to None
    
+
    Defaults to None
    
 
-                
    data
    
+
    data
    
 
-                
    similar to genrule.srcs
-                    may also include targets that produce or reference npm packages which are needed by the tool
    
+
    similar to genrule.srcs
+may also include targets that produce or reference npm packages which are needed by the tool
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    outs
    
+
    outs
    
 
-                
    similar to genrule.outs
    
+
    similar to genrule.outs
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    args
    
+
    args
    
 
-                
    Command-line arguments to the tool.
    
+
    Command-line arguments to the tool.
    
 
-                
    Subject to ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.
    
+
    Subject to ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.
    
 
-                
      
-                    
    1. Predefined source/output path substitions is applied first:
      2. 
-                
    
+
      
+  
    1. Predefined source/output path substitions is applied first:
      2. 
+
    
 
-                
    See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_label_variables.
    
+
    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 $(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.
    
+
    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.
    
+
    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.
    
+
    Using $(location) and $(locations) expansions is not recommended as these are a synonyms
+for either $(execpath) or $(rootpath) depending on the context.
    
 
-                
      
-                    
    1. “Make” variables are expanded second:
      2. 
-                
    
+
      
+  
    1. “Make” variables are expanded second:
      2. 
+
    
 
-                
    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 “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.
    
+
    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)
      • 
-                
    
+
      
+  
    • $@: 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.
    
+
    See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_genrule_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.
    
+
    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.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    output_dir
    
+
    output_dir
    
 
-                
    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.
    
+
    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
    
+
    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.
    
+
    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
    
+
    Defaults to False
    
 
-                
    kwargs
    
+
    kwargs
    
 
-                
    params_file
    
+
    params_file
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     params_file(name, out, args, data, newline, kwargs)
 
    
 
-                
    Generates a UTF-8 encoded params file from a list of arguments.
    
+
    Generates a UTF-8 encoded params file from a list of arguments.
    
 
-                
    Handles variable substitutions for args.
    
+
    Handles variable substitutions for args.
    
 
-                
    PARAMETERS
    
+
    PARAMETERS
    
 
-                
    name
    
+
    name
    
 
-                
    Name of the rule.
    
+
    Name of the rule.
    
 
-                
    out
    
+
    out
    
 
-                
    Path of the output file, relative to this package.
    
+
    Path of the output file, relative to this package.
    
 
-                
    args
    
+
    args
    
 
-                
    Arguments to concatenate into a params file.
    
+
    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 ‘Make variable’ substitution. See https://docs.bazel.build/versions/master/be/make-variables.html.
    
 
-                
      
-                    
    1. Subject to predefined source/output path variables substitutions.
      2. 
-                
    
+
      
+  
    1. Subject to predefined source/output path variables substitutions.
      2. 
+
    
 
-                
    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.
    
+
    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.
    
+
    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.
    
+
    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.
    
 
-                
      
-                    
    1. Subject to predefined variables & custom variable substitutions.
      2. 
-                
    
+
      
+  
    1. Subject to predefined variables & custom variable substitutions.
      2. 
+
    
 
-                
    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 “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.
    
+
    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.
    
+
    Predefined genrule variables are not supported in this context.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    data
    
+
    data
    
 
-                
    Data for $(location) expansions in args.
    
+
    Data for $(location) expansions in args.
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    newline
    
+
    newline
    
 
-                
    Line endings to use. One of [“auto”, “unix”, “windows”].
    
+
    Line endings to use. One of [“auto”, “unix”, “windows”].
    
 
-                
    “auto” for platform-determined
-                    “unix” for LF
-                    “windows” for CRLF
    
+
    “auto” for platform-determined
+“unix” for LF
+“windows” for CRLF
    
 
-                
    Defaults to "auto"
    
+
    Defaults to "auto"
    
 
-                
    kwargs
    
+
    kwargs
    
 
-                
    DeclarationInfo
    
+
    DeclarationInfo
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     DeclarationInfo(declarations, transitive_declarations, type_blacklisted_declarations)
 
    
 
-                
    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.
    
+
    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.
    
+
    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.
    
+
    Note: historically this was a subset of the string-typed “typescript” provider.
    
 
-                
    FIELDS
    
+
    FIELDS
    
 
-                
    declarations
    
+
    declarations
    
 
-                
    A depset of typings files produced by this rule
    
-                
    transitive_declarations
    
+
    A depset of typings files produced by this rule
    
+
    transitive_declarations
    
 
-                
    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.
    
-                
    type_blacklisted_declarations
    
+
    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.
    
+
    type_blacklisted_declarations
    
 
-                
    A depset of .d.ts files that we should not use to infer JSCompiler types (via tsickle)
    
+
    A depset of .d.ts files that we should not use to infer JSCompiler types (via tsickle)
    
 
-                
    JSEcmaScriptModuleInfo
    
+
    JSEcmaScriptModuleInfo
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     JSEcmaScriptModuleInfo(direct_sources, sources)
 
    
 
-                
    JavaScript files (and sourcemaps) that are intended to be consumed by downstream tooling.
    
+
    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”
    
+
    They should use modern syntax and ESModules.
+These files should typically be named “foo.mjs”
    
 
-                
    Historical note: this was the typescript.es6_sources output
    
+
    Historical note: this was the typescript.es6_sources output
    
 
-                
    FIELDS
    
+
    FIELDS
    
 
-                
    direct_sources
    
+
    direct_sources
    
 
-                
    Depset of direct JavaScript files and sourcemaps
    
-                
    sources
    
+
    Depset of direct JavaScript files and sourcemaps
    
+
    sources
    
 
-                
    Depset of direct and transitive JavaScript files and sourcemaps
    
+
    Depset of direct and transitive JavaScript files and sourcemaps
    
 
-                
    JSModuleInfo
    
+
    JSModuleInfo
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     JSModuleInfo(direct_sources, sources)
 
    
 
-                
    JavaScript files and sourcemaps.
    
+
    JavaScript files and sourcemaps.
    
 
-                
    FIELDS
    
+
    FIELDS
    
 
-                
    direct_sources
    
+
    direct_sources
    
 
-                
    Depset of direct JavaScript files and sourcemaps
    
-                
    sources
    
+
    Depset of direct JavaScript files and sourcemaps
    
+
    sources
    
 
-                
    Depset of direct and transitive JavaScript files and sourcemaps
    
+
    Depset of direct and transitive JavaScript files and sourcemaps
    
 
-                
    JSNamedModuleInfo
    
+
    JSNamedModuleInfo
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     JSNamedModuleInfo(direct_sources, sources)
 
    
 
-                
    JavaScript files whose module name is self-contained.
    
+
    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)
    
+
    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.
    
+
    Historical note: this was the typescript.es5_sources output.
    
 
-                
    FIELDS
    
+
    FIELDS
    
 
-                
    direct_sources
    
+
    direct_sources
    
 
-                
    Depset of direct JavaScript files and sourcemaps
    
-                
    sources
    
+
    Depset of direct JavaScript files and sourcemaps
    
+
    sources
    
 
-                
    Depset of direct and transitive JavaScript files and sourcemaps
    
+
    Depset of direct and transitive JavaScript files and sourcemaps
    
 
-                
    LinkablePackageInfo
    
+
    LinkablePackageInfo
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     LinkablePackageInfo(files, package_name, path, _tslibrary)
 
    
 
-                
    The LinkablePackageInfo provider provides information to the linker for linking pkg_npm built packages
    
+
    The LinkablePackageInfo provider provides information to the linker for linking pkg_npm built packages
    
 
-                
    FIELDS
    
+
    FIELDS
    
 
-                
    files
    
+
    files
    
 
-                
    Depset of files in this package (must all be contained within path)
    
-                
    package_name
    
+
    Depset of files in this package (must all be contained within path)
    
+
    package_name
    
 
-                
    The package name.
    
+
    The package name.
    
 
-                
    Should be the same as name field in the package’s package.json.
    
+
    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.
    
-                
    path
    
+
    In the future, the linker may validate that the names match the name in a package.json file.
    
+
    path
    
 
-                
    The path to link to.
    
+
    The path to link to.
    
 
-                
    Path must be relative to execroot/wksp. It can either an output dir path such as,
    
+
    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
    
+
    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,
    
+
    or a source file path such as,
    
 
-                
    path/to/package or
-                    external/<external_wksp>/path/to/package
    
-                
    _tslibrary
    
+
    path/to/package or
+external/<external_wksp>/path/to/package
    
+
    _tslibrary
    
 
-                
    For internal use only
    
+
    For internal use only
    
 
-                
    NodeContextInfo
    
+
    NodeContextInfo
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     NodeContextInfo(stamp)
 
    
 
-                
    Provides data about the build context, like config_setting’s
    
+
    Provides data about the build context, like config_setting’s
    
 
-                
    FIELDS
    
+
    FIELDS
    
 
-                
    stamp
    
+
    stamp
    
 
-                
    If stamping is enabled
    
+
    If stamping is enabled
    
 
-                
    NodeRuntimeDepsInfo
    
+
    NodeRuntimeDepsInfo
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     NodeRuntimeDepsInfo(deps, pkgs)
 
    
 
-                
    Stores runtime dependencies of a nodejs_binary or nodejs_test
    
+
    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.
    
+
    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.
    
+
    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.
    
+
    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
    
+
    FIELDS
    
 
-                
    deps
    
+
    deps
    
 
-                
    depset of runtime dependency labels
    
-                
    pkgs
    
+
    depset of runtime dependency labels
    
+
    pkgs
    
 
-                
    list of labels of packages that provide NpmPackageInfo
    
+
    list of labels of packages that provide NpmPackageInfo
    
 
-                
    NpmPackageInfo
    
+
    NpmPackageInfo
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     NpmPackageInfo(direct_sources, sources, workspace)
 
    
 
-                
    Provides information about npm dependencies
    
+
    Provides information about npm dependencies
    
 
-                
    FIELDS
    
+
    FIELDS
    
 
-                
    direct_sources
    
+
    direct_sources
    
 
-                
    Depset of direct source files in this npm package
    
-                
    sources
    
+
    Depset of direct source files in this npm package
    
+
    sources
    
 
-                
    Depset of direct & transitive source files in this npm package and in its dependencies
    
-                
    workspace
    
+
    Depset of direct & transitive source files in this npm package and in its dependencies
    
+
    workspace
    
 
-                
    The workspace name that this npm package is provided from
    
+
    The workspace name that this npm package is provided from
    
 
-                
    declaration_info
    
+
    declaration_info
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     declaration_info(declarations, deps)
 
    
 
-                
    Constructs a DeclarationInfo including all transitive files needed to type-check from DeclarationInfo providers in a list of deps.
    
+
    Constructs a DeclarationInfo including all transitive files needed to type-check from DeclarationInfo providers in a list of deps.
    
 
-                
    PARAMETERS
    
+
    PARAMETERS
    
 
-                
    declarations
    
+
    declarations
    
 
-                
    list of typings files
    
+
    list of typings files
    
 
-                
    deps
    
+
    deps
    
 
-                
    list of labels of dependencies where we should collect their DeclarationInfo to pass transitively
    
+
    list of labels of dependencies where we should collect their DeclarationInfo to pass transitively
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    js_ecma_script_module_info
    
+
    js_ecma_script_module_info
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     js_ecma_script_module_info(sources, deps)
 
    
 
-                
    Constructs a JSEcmaScriptModuleInfo including all transitive sources from JSEcmaScriptModuleInfo providers in a list of deps.
    
+
    Constructs a JSEcmaScriptModuleInfo including all transitive sources from JSEcmaScriptModuleInfo providers in a list of deps.
    
 
-                
    Returns a single JSEcmaScriptModuleInfo.
    
+
    Returns a single JSEcmaScriptModuleInfo.
    
 
-                
    PARAMETERS
    
+
    PARAMETERS
    
 
-                
    sources
    
+
    sources
    
 
-                
    deps
    
+
    deps
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    js_module_info
    
+
    js_module_info
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     js_module_info(sources, deps)
 
    
 
-                
    Constructs a JSModuleInfo including all transitive sources from JSModuleInfo providers in a list of deps.
    
+
    Constructs a JSModuleInfo including all transitive sources from JSModuleInfo providers in a list of deps.
    
 
-                
    Returns a single JSModuleInfo.
    
+
    Returns a single JSModuleInfo.
    
 
-                
    PARAMETERS
    
+
    PARAMETERS
    
 
-                
    sources
    
+
    sources
    
 
-                
    deps
    
+
    deps
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    js_named_module_info
    
+
    js_named_module_info
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     js_named_module_info(sources, deps)
 
    
 
-                
    Constructs a JSNamedModuleInfo including all transitive sources from JSNamedModuleInfo providers in a list of deps.
    
+
    Constructs a JSNamedModuleInfo including all transitive sources from JSNamedModuleInfo providers in a list of deps.
    
 
-                
    Returns a single JSNamedModuleInfo.
    
+
    Returns a single JSNamedModuleInfo.
    
 
-                
    PARAMETERS
    
+
    PARAMETERS
    
 
-                
    sources
    
+
    sources
    
 
-                
    deps
    
+
    deps
    
 
-                
    Defaults to []
    
+
    Defaults to []
    
 
-                
    run_node
    
+
    run_node
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     run_node(ctx, inputs, arguments, executable, kwargs)
 
    
 
-                
    Helper to replace ctx.actions.run
    
+
    Helper to replace ctx.actions.run
    
 
-                
    This calls node programs with a node_modules directory in place
    
+
    This calls node programs with a node_modules directory in place
    
 
-                
    PARAMETERS
    
+
    PARAMETERS
    
 
-                
    ctx
    
+
    ctx
    
 
-                
    rule context from the calling rule implementation function
    
+
    rule context from the calling rule implementation function
    
 
-                
    inputs
    
+
    inputs
    
 
-                
    list or depset of inputs to the action
    
+
    list or depset of inputs to the action
    
 
-                
    arguments
    
+
    arguments
    
 
-                
    list or ctx.actions.Args object containing arguments to pass to the executable
    
+
    list or ctx.actions.Args object containing arguments to pass to the executable
    
 
-                
    executable
    
+
    executable
    
 
-                
    stringy representation of the executable this action will run, eg eg. “my_executable” rather than ctx.executable.my_executable
    
+
    stringy representation of the executable this action will run, eg eg. “my_executable” rather than ctx.executable.my_executable
    
 
-                
    kwargs
    
+
    kwargs
    
 
-                
    node_modules_aspect
    
+
    node_modules_aspect
    
 
-                
    USAGE
    
+
    USAGE
    
 
-                
    +
     node_modules_aspect(name)
 
    
 
-                
    ASPECT ATTRIBUTES
    
+
    ASPECT ATTRIBUTES
    
 
-                
    deps
    
+
    deps
    
 
-                
    ATTRIBUTES
    
+
    ATTRIBUTES
    
 
-                
    name
    
+
    name
    
 
-                
    (Name, {util.mandatoryString(name: “name”
+
    (Name, {util.mandatoryString(name: “name”
 doc_string: “A unique name for this target.”
 type: NAME
 mandatory: true
 )})
-                    A unique name for this target.
    
+ A unique name for this target.
    
 
 
-            
    
-        
    
+      
    
+    
    
 
-        
    
-            
    
-                
-                
-            
    
-        
    
+    
    
+      
    
+        
+        
+      
    
     
    
+  
    
 
    
 
 
    
-    
    
-        
    
-            
    
-                
    © 2020 The rules_nodejs authors
    
-            
    
-        
    
+  
    
+  
    
+    
    
+      
    © 2020 The rules_nodejs authors
    
     
    
+  
    
+
    
 
 
    
 
@@ -2245,62 +2245,63 @@ 
    name
    
 
 
 
 
 
 
 
 
+
diff --git a/docs/Built-ins.md b/docs/Built-ins.md
index 62c379affa..bd7ec7d1af 100755
--- a/docs/Built-ins.md
+++ b/docs/Built-ins.md
@@ -2183,3 +2183,4 @@ mandatory: true
  A unique name for this target. 
 
 
+

From 22d44fd2a387966b2a4b1c8dd1a9e644689870b5 Mon Sep 17 00:00:00 2001
From: Tiago Costa 
Date: Wed, 16 Dec 2020 18:35:56 +0000
Subject: [PATCH 5/9] docs(builtin): update generated docs

---
 docs/Built-ins.html | 61 ++++++++++++++++++++++++++++++++++++++++---
 docs/Built-ins.md   | 63 ++++++++++++++++++++++++++++++++++++++++++---
 docs/install.html   |  4 +--
 3 files changed, 120 insertions(+), 8 deletions(-)

diff --git a/docs/Built-ins.html b/docs/Built-ins.html
index 87c90eed1c..243b0a6389 100755
--- a/docs/Built-ins.html
+++ b/docs/Built-ins.html
@@ -949,6 +949,26 @@ 
    npm_install
    
 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.
    
 
+
    LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL
    
+
+
    When using a monorepo is common to have locally written modules that we both
+want to use locally while publicly publishing them. That is not much of a problem
+as we can use a js_library rule with a package_name attribute defined inside the
+local package BUILD file. However, if we are in the middle of transition into bazel,
+or we have any other requirement to use that local package outside bazel we will also
+have to declare and install the local package with file: in the monorepo package.json
+dependencies, which could introduce a race condition within the npm_install rule.
    
+
+
    In order to overcome it, a link will be created to the package BUILD file from the
+npm external Bazel repository, which require us to complete a last step which is writing
+the expected targets on that same BUILD file to be later used by the npm_install
+rule, which are: <package_name__files>, <package_name__nested_node_modules>,
+<package_name__contents>, <package_name__typings> and the last
+one just <package_name>.
    
+
+
    If you doubt what those targets should look like, check the
+generated BUILD file for a given node module.
    
+
 
    ATTRIBUTES
    
 
 
    name
    
@@ -1250,9 +1270,9 @@ 
    yarn_install
    
 
    USAGE
    
 
 
    -yarn_install(name, args, data, environment, included_files, manual_build_file_contents,
-             package_json, quiet, repo_mapping, strict_visibility, symlink_node_modules, timeout,
-             use_global_yarn_cache, yarn_lock)
+yarn_install(name, args, data, environment, frozen_lockfile, included_files,
+             manual_build_file_contents, package_json, quiet, repo_mapping, strict_visibility,
+             symlink_node_modules, timeout, use_global_yarn_cache, yarn_lock)
 
    
 
 
    Runs yarn install during workspace setup.
    
@@ -1261,6 +1281,26 @@ 
    yarn_install
    
 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.
    
 
+
    LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL
    
+
+
    When using a monorepo is common to have locally written modules that we both
+want to use locally while publicly publishing them. That is not much of a problem
+as we can use a js_library rule with a package_name attribute defined inside the
+local package BUILD file. However, if we are in the middle of transition into bazel,
+or we have any other requirement to use that local package outside bazel we will also
+have to declare and install the local package with link: in the monorepo package.json
+dependencies, which could introduce a race condition within the yarn_install rule.
    
+
+
    In order to overcome it, a link will be created to the package BUILD file from the
+npm external Bazel repository, which require us to complete a last step which is writing
+the expected targets on that same BUILD file to be later used by the yarn_install
+rule, which are: <package_name__files>, <package_name__nested_node_modules>,
+<package_name__contents>, <package_name__typings> and the last
+one just <package_name>.
    
+
+
    If you doubt what those targets should look like, check the
+generated BUILD file for a given node module.
    
+
 
    ATTRIBUTES
    
 
 
    name
    
@@ -1296,6 +1336,21 @@ 
    environment
    
 
 
    Defaults to {}
    
 
+
    frozen_lockfile
    
+
+
    (Boolean): Use the --frozen-lockfile flag for yarn.
    
+
+
    Don’t generate a yarn.lock lockfile and fail if an update is needed.
    
+
+
    This flag enables an exact install of the version that is specified in the yarn.lock
+file. This helps to have reproduceable builds across builds.
    
+
+
    To update a dependency or install a new one run the yarn install command with the
+vendored yarn binary. bazel run @nodejs//:yarn install. You can pass the options like
+bazel run @nodejs//:yarn install -- -D <dep-name>.
    
+
+
    Defaults to True
    
+
 
    included_files
    
 
 
    (List of strings): List of file extensions to be included in the npm package targets.
    
diff --git a/docs/Built-ins.md b/docs/Built-ins.md
index bd7ec7d1af..0bb2d91c12 100755
--- a/docs/Built-ins.md
+++ b/docs/Built-ins.md
@@ -833,6 +833,27 @@ This rule will set the environment variable `BAZEL_NPM_INSTALL` to '1' (unless i
 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.
 
+
+**LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL**
+
+When using a monorepo is common to have locally written modules that we both
+want to use locally while publicly publishing them. That is not much of a problem
+as we can use a `js_library` rule with a `package_name` attribute defined inside the
+local package `BUILD` file. However, if we are in the middle of transition into bazel,
+or we have any other requirement to use that local package outside bazel we will also
+have to declare and install the local package with `file:` in the monorepo `package.json`
+dependencies, which could introduce a race condition within the `npm_install rule`.
+
+In order to overcome it, a link will be created to the package `BUILD` file from the
+npm external Bazel repository, which require us to complete a last step which is writing
+the expected targets on that same `BUILD` file to be later used by the `npm_install`
+rule, which are: ``, ``,
+``, `` and the last
+one just ``.
+
+If you doubt what those targets should look like, check the
+generated `BUILD` file for a given node module.
+
 **ATTRIBUTES**
 
 
@@ -1157,9 +1178,9 @@ Defaults to `{}`
 **USAGE**
 
 
    -yarn_install(name, args, data, environment, included_files, manual_build_file_contents,
-             package_json, quiet, repo_mapping, strict_visibility, symlink_node_modules, timeout,
-             use_global_yarn_cache, yarn_lock)
+yarn_install(name, args, data, environment, frozen_lockfile, included_files,
+             manual_build_file_contents, package_json, quiet, repo_mapping, strict_visibility,
+             symlink_node_modules, timeout, use_global_yarn_cache, yarn_lock)
 
    
 
 Runs yarn install during workspace setup.
@@ -1168,6 +1189,27 @@ This rule will set the environment variable `BAZEL_YARN_INSTALL` to '1' (unless
 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.
 
+
+**LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL**
+
+When using a monorepo is common to have locally written modules that we both
+want to use locally while publicly publishing them. That is not much of a problem
+as we can use a `js_library` rule with a `package_name` attribute defined inside the
+local package `BUILD` file. However, if we are in the middle of transition into bazel,
+or we have any other requirement to use that local package outside bazel we will also
+have to declare and install the local package with `link:` in the monorepo `package.json`
+dependencies, which could introduce a race condition within the `yarn_install rule`.
+
+In order to overcome it, a link will be created to the package `BUILD` file from the
+npm external Bazel repository, which require us to complete a last step which is writing
+the expected targets on that same `BUILD` file to be later used by the `yarn_install`
+rule, which are: ``, ``,
+``, `` and the last
+one just ``.
+
+If you doubt what those targets should look like, check the
+generated `BUILD` file for a given node module.
+
 **ATTRIBUTES**
 
 
@@ -1205,6 +1247,21 @@ Defaults to `[]`
 
 Defaults to `{}`
 
+
    frozen_lockfile
    
+
+(*Boolean*): Use the `--frozen-lockfile` flag for yarn.
+
+Don’t generate a `yarn.lock` lockfile and fail if an update is needed.
+
+This flag enables an exact install of the version that is specified in the `yarn.lock`
+file. This helps to have reproduceable builds across builds.
+
+To update a dependency or install a new one run the `yarn install` command with the
+vendored yarn binary. `bazel run @nodejs//:yarn install`. You can pass the options like
+`bazel run @nodejs//:yarn install -- -D `.
+
+Defaults to `True`
+
 
    included_files
    
 
 (*List of strings*): List of file extensions to be included in the npm package targets.
diff --git a/docs/install.html b/docs/install.html
index d4db6cf114..f152d8653d 100755
--- a/docs/install.html
+++ b/docs/install.html
@@ -187,8 +187,8 @@ 
    Custom installation
    
 
    load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
 http_archive(
     name = "build_bazel_rules_nodejs",
-    sha256 = "f2194102720e662dbf193546585d705e645314319554c6ce7e47d8b59f459e9c",
-    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/2.2.2/rules_nodejs-2.2.2.tar.gz"],
+    sha256 = "290b659e7a6323e442db922175a4838e4ac622509f9e9fa0dd16b7ca30377d68",
+    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/3.0.0-rc.0/rules_nodejs-3.0.0-rc.0.tar.gz"],
 )
 
 load("@build_bazel_rules_nodejs//:index.bzl", "node_repositories")

From fd0a9847a4359c0ccb1919e7ff19e5bc6de2055b Mon Sep 17 00:00:00 2001
From: Tiago Costa 
Date: Wed, 16 Dec 2020 18:48:04 +0000
Subject: [PATCH 6/9] docs(builtin): update introduced docs to be more concise

---
 docs/Built-ins.html                  | 24 ++++++++++--------------
 docs/Built-ins.md                    | 24 ++++++++++--------------
 internal/npm_install/npm_install.bzl | 24 ++++++++++--------------
 3 files changed, 30 insertions(+), 42 deletions(-)

diff --git a/docs/Built-ins.html b/docs/Built-ins.html
index 243b0a6389..5d477ec509 100755
--- a/docs/Built-ins.html
+++ b/docs/Built-ins.html
@@ -951,13 +951,11 @@ 
    npm_install
    
 
 
    LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL
    
 
-
    When using a monorepo is common to have locally written modules that we both
-want to use locally while publicly publishing them. That is not much of a problem
-as we can use a js_library rule with a package_name attribute defined inside the
-local package BUILD file. However, if we are in the middle of transition into bazel,
-or we have any other requirement to use that local package outside bazel we will also
-have to declare and install the local package with file: in the monorepo package.json
-dependencies, which could introduce a race condition within the npm_install rule.
    
+
    When using a monorepo it’s common to have modules that we want to use locally and
+publish to an external package repository. This can be achieved using a js_library rule
+with a package_name attribute defined inside the local package BUILD file. However,
+if the project relies on the local package dependency with file:, this could introduce a
+race condition with the npm_install rule.
    
 
 
    In order to overcome it, a link will be created to the package BUILD file from the
 npm external Bazel repository, which require us to complete a last step which is writing
@@ -1283,13 +1281,11 @@ 
    yarn_install
    
 
 
    LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL
    
 
-
    When using a monorepo is common to have locally written modules that we both
-want to use locally while publicly publishing them. That is not much of a problem
-as we can use a js_library rule with a package_name attribute defined inside the
-local package BUILD file. However, if we are in the middle of transition into bazel,
-or we have any other requirement to use that local package outside bazel we will also
-have to declare and install the local package with link: in the monorepo package.json
-dependencies, which could introduce a race condition within the yarn_install rule.
    
+
    When using a monorepo it’s common to have modules that we want to use locally and
+publish to an external package repository. This can be achieved using a js_library rule
+with a package_name attribute defined inside the local package BUILD file. However,
+if the project relies on the local package dependency with link:, this could introduce a
+race condition with the yarn_install rule.
    
 
 
    In order to overcome it, a link will be created to the package BUILD file from the
 npm external Bazel repository, which require us to complete a last step which is writing
diff --git a/docs/Built-ins.md b/docs/Built-ins.md
index 0bb2d91c12..9d2a1d97ce 100755
--- a/docs/Built-ins.md
+++ b/docs/Built-ins.md
@@ -836,13 +836,11 @@ check if yarn is being run by the `npm_install` repository rule.
 
 **LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL**
 
-When using a monorepo is common to have locally written modules that we both
-want to use locally while publicly publishing them. That is not much of a problem
-as we can use a `js_library` rule with a `package_name` attribute defined inside the
-local package `BUILD` file. However, if we are in the middle of transition into bazel,
-or we have any other requirement to use that local package outside bazel we will also
-have to declare and install the local package with `file:` in the monorepo `package.json`
-dependencies, which could introduce a race condition within the `npm_install rule`.
+When using a monorepo it's common to have modules that we want to use locally and
+publish to an external package repository. This can be achieved using a `js_library` rule
+with a `package_name` attribute defined inside the local package `BUILD` file. However,
+if the project relies on the local package dependency with `file:`, this could introduce a
+race condition with the `npm_install` rule.
 
 In order to overcome it, a link will be created to the package `BUILD` file from the
 npm external Bazel repository, which require us to complete a last step which is writing
@@ -1192,13 +1190,11 @@ check if yarn is being run by the `yarn_install` repository rule.
 
 **LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL**
 
-When using a monorepo is common to have locally written modules that we both
-want to use locally while publicly publishing them. That is not much of a problem
-as we can use a `js_library` rule with a `package_name` attribute defined inside the
-local package `BUILD` file. However, if we are in the middle of transition into bazel,
-or we have any other requirement to use that local package outside bazel we will also
-have to declare and install the local package with `link:` in the monorepo `package.json`
-dependencies, which could introduce a race condition within the `yarn_install rule`.
+When using a monorepo it's common to have modules that we want to use locally and
+publish to an external package repository. This can be achieved using a `js_library` rule
+with a `package_name` attribute defined inside the local package `BUILD` file. However,
+if the project relies on the local package dependency with `link:`, this could introduce a
+race condition with the `yarn_install` rule.
 
 In order to overcome it, a link will be created to the package `BUILD` file from the
 npm external Bazel repository, which require us to complete a last step which is writing
diff --git a/internal/npm_install/npm_install.bzl b/internal/npm_install/npm_install.bzl
index 881b4b5d6f..d6cc926d5c 100644
--- a/internal/npm_install/npm_install.bzl
+++ b/internal/npm_install/npm_install.bzl
@@ -317,13 +317,11 @@ check if yarn is being run by the `npm_install` repository rule.
 
 **LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL**
 
-When using a monorepo is common to have locally written modules that we both
-want to use locally while publicly publishing them. That is not much of a problem
-as we can use a `js_library` rule with a `package_name` attribute defined inside the
-local package `BUILD` file. However, if we are in the middle of transition into bazel,
-or we have any other requirement to use that local package outside bazel we will also
-have to declare and install the local package with `file:` in the monorepo `package.json`
-dependencies, which could introduce a race condition within the `npm_install rule`.
+When using a monorepo it's common to have modules that we want to use locally and
+publish to an external package repository. This can be achieved using a `js_library` rule
+with a `package_name` attribute defined inside the local package `BUILD` file. However,
+if the project relies on the local package dependency with `file:`, this could introduce a
+race condition with the `npm_install` rule.
 
 In order to overcome it, a link will be created to the package `BUILD` file from the
 npm external Bazel repository, which require us to complete a last step which is writing
@@ -501,13 +499,11 @@ check if yarn is being run by the `yarn_install` repository rule.
 
 **LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL**
 
-When using a monorepo is common to have locally written modules that we both
-want to use locally while publicly publishing them. That is not much of a problem
-as we can use a `js_library` rule with a `package_name` attribute defined inside the
-local package `BUILD` file. However, if we are in the middle of transition into bazel,
-or we have any other requirement to use that local package outside bazel we will also
-have to declare and install the local package with `link:` in the monorepo `package.json`
-dependencies, which could introduce a race condition within the `yarn_install rule`.
+When using a monorepo it's common to have modules that we want to use locally and
+publish to an external package repository. This can be achieved using a `js_library` rule
+with a `package_name` attribute defined inside the local package `BUILD` file. However,
+if the project relies on the local package dependency with `link:`, this could introduce a
+race condition with the `yarn_install` rule.
 
 In order to overcome it, a link will be created to the package `BUILD` file from the
 npm external Bazel repository, which require us to complete a last step which is writing

From 1abf07c31cfdca4865d6e10155cd4d93856898c4 Mon Sep 17 00:00:00 2001
From: Tiago Costa 
Date: Wed, 16 Dec 2020 21:39:49 +0000
Subject: [PATCH 7/9] docs(builtin): complete docs

---
 docs/Built-ins.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/Built-ins.md b/docs/Built-ins.md
index 9d2a1d97ce..6080621799 100755
--- a/docs/Built-ins.md
+++ b/docs/Built-ins.md
@@ -2156,7 +2156,7 @@ Returns a single JSNamedModuleInfo.
 
 
 
-
    deps
    
+deps
 
 
 Defaults to `[]`

From 2e0e4337a112eb95d783d6564246fd0024d01ac8 Mon Sep 17 00:00:00 2001
From: Tiago Costa 
Date: Wed, 16 Dec 2020 21:40:04 +0000
Subject: [PATCH 8/9] docs(builtin): remove docs typo

---
 docs/Built-ins.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/Built-ins.md b/docs/Built-ins.md
index 6080621799..9d2a1d97ce 100755
--- a/docs/Built-ins.md
+++ b/docs/Built-ins.md
@@ -2156,7 +2156,7 @@ Returns a single JSNamedModuleInfo.
 
 
 
-deps
+
    deps
    
 
 
 Defaults to `[]`

From 859393103b5c2334e7db3ef05ab9bf42ceeb37b2 Mon Sep 17 00:00:00 2001
From: Alex Eagle 
Date: Wed, 16 Dec 2020 14:42:22 -0800
Subject: [PATCH 9/9] restore docs

---
 docs/Built-ins.html | 57 +++----------------------------------------
 docs/Built-ins.md   | 59 +++------------------------------------------
 docs/install.html   |  4 +--
 3 files changed, 8 insertions(+), 112 deletions(-)

diff --git a/docs/Built-ins.html b/docs/Built-ins.html
index 5d477ec509..87c90eed1c 100755
--- a/docs/Built-ins.html
+++ b/docs/Built-ins.html
@@ -949,24 +949,6 @@ 
    npm_install
    
 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.
    
 
-
    LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL
    
-
-
    When using a monorepo it’s common to have modules that we want to use locally and
-publish to an external package repository. This can be achieved using a js_library rule
-with a package_name attribute defined inside the local package BUILD file. However,
-if the project relies on the local package dependency with file:, this could introduce a
-race condition with the npm_install rule.
    
-
-
    In order to overcome it, a link will be created to the package BUILD file from the
-npm external Bazel repository, which require us to complete a last step which is writing
-the expected targets on that same BUILD file to be later used by the npm_install
-rule, which are: <package_name__files>, <package_name__nested_node_modules>,
-<package_name__contents>, <package_name__typings> and the last
-one just <package_name>.
    
-
-
    If you doubt what those targets should look like, check the
-generated BUILD file for a given node module.
    
-
 
    ATTRIBUTES
    
 
 
    name
    
@@ -1268,9 +1250,9 @@ 
    yarn_install
    
 
    USAGE
    
 
 
    -yarn_install(name, args, data, environment, frozen_lockfile, included_files,
-             manual_build_file_contents, package_json, quiet, repo_mapping, strict_visibility,
-             symlink_node_modules, timeout, use_global_yarn_cache, yarn_lock)
+yarn_install(name, args, data, environment, included_files, manual_build_file_contents,
+             package_json, quiet, repo_mapping, strict_visibility, symlink_node_modules, timeout,
+             use_global_yarn_cache, yarn_lock)
 
    
 
 
    Runs yarn install during workspace setup.
    
@@ -1279,24 +1261,6 @@ 
    yarn_install
    
 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.
    
 
-
    LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL
    
-
-
    When using a monorepo it’s common to have modules that we want to use locally and
-publish to an external package repository. This can be achieved using a js_library rule
-with a package_name attribute defined inside the local package BUILD file. However,
-if the project relies on the local package dependency with link:, this could introduce a
-race condition with the yarn_install rule.
    
-
-
    In order to overcome it, a link will be created to the package BUILD file from the
-npm external Bazel repository, which require us to complete a last step which is writing
-the expected targets on that same BUILD file to be later used by the yarn_install
-rule, which are: <package_name__files>, <package_name__nested_node_modules>,
-<package_name__contents>, <package_name__typings> and the last
-one just <package_name>.
    
-
-
    If you doubt what those targets should look like, check the
-generated BUILD file for a given node module.
    
-
 
    ATTRIBUTES
    
 
 
    name
    
@@ -1332,21 +1296,6 @@ 
    environment
    
 
 
    Defaults to {}
    
 
-
    frozen_lockfile
    
-
-
    (Boolean): Use the --frozen-lockfile flag for yarn.
    
-
-
    Don’t generate a yarn.lock lockfile and fail if an update is needed.
    
-
-
    This flag enables an exact install of the version that is specified in the yarn.lock
-file. This helps to have reproduceable builds across builds.
    
-
-
    To update a dependency or install a new one run the yarn install command with the
-vendored yarn binary. bazel run @nodejs//:yarn install. You can pass the options like
-bazel run @nodejs//:yarn install -- -D <dep-name>.
    
-
-
    Defaults to True
    
-
 
    included_files
    
 
 
    (List of strings): List of file extensions to be included in the npm package targets.
    
diff --git a/docs/Built-ins.md b/docs/Built-ins.md
index 9d2a1d97ce..bd7ec7d1af 100755
--- a/docs/Built-ins.md
+++ b/docs/Built-ins.md
@@ -833,25 +833,6 @@ This rule will set the environment variable `BAZEL_NPM_INSTALL` to '1' (unless i
 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.
 
-
-**LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL**
-
-When using a monorepo it's common to have modules that we want to use locally and
-publish to an external package repository. This can be achieved using a `js_library` rule
-with a `package_name` attribute defined inside the local package `BUILD` file. However,
-if the project relies on the local package dependency with `file:`, this could introduce a
-race condition with the `npm_install` rule.
-
-In order to overcome it, a link will be created to the package `BUILD` file from the
-npm external Bazel repository, which require us to complete a last step which is writing
-the expected targets on that same `BUILD` file to be later used by the `npm_install`
-rule, which are: ``, ``,
-``, `` and the last
-one just ``.
-
-If you doubt what those targets should look like, check the
-generated `BUILD` file for a given node module.
-
 **ATTRIBUTES**
 
 
@@ -1176,9 +1157,9 @@ Defaults to `{}`
 **USAGE**
 
 
    -yarn_install(name, args, data, environment, frozen_lockfile, included_files,
-             manual_build_file_contents, package_json, quiet, repo_mapping, strict_visibility,
-             symlink_node_modules, timeout, use_global_yarn_cache, yarn_lock)
+yarn_install(name, args, data, environment, included_files, manual_build_file_contents,
+             package_json, quiet, repo_mapping, strict_visibility, symlink_node_modules, timeout,
+             use_global_yarn_cache, yarn_lock)
 
    
 
 Runs yarn install during workspace setup.
@@ -1187,25 +1168,6 @@ This rule will set the environment variable `BAZEL_YARN_INSTALL` to '1' (unless
 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.
 
-
-**LOCAL MODULES WITH THE NEED TO BE USED BOTH INSIDE AND OUTSIDE BAZEL**
-
-When using a monorepo it's common to have modules that we want to use locally and
-publish to an external package repository. This can be achieved using a `js_library` rule
-with a `package_name` attribute defined inside the local package `BUILD` file. However,
-if the project relies on the local package dependency with `link:`, this could introduce a
-race condition with the `yarn_install` rule.
-
-In order to overcome it, a link will be created to the package `BUILD` file from the
-npm external Bazel repository, which require us to complete a last step which is writing
-the expected targets on that same `BUILD` file to be later used by the `yarn_install`
-rule, which are: ``, ``,
-``, `` and the last
-one just ``.
-
-If you doubt what those targets should look like, check the
-generated `BUILD` file for a given node module.
-
 **ATTRIBUTES**
 
 
@@ -1243,21 +1205,6 @@ Defaults to `[]`
 
 Defaults to `{}`
 
-
    frozen_lockfile
    
-
-(*Boolean*): Use the `--frozen-lockfile` flag for yarn.
-
-Don’t generate a `yarn.lock` lockfile and fail if an update is needed.
-
-This flag enables an exact install of the version that is specified in the `yarn.lock`
-file. This helps to have reproduceable builds across builds.
-
-To update a dependency or install a new one run the `yarn install` command with the
-vendored yarn binary. `bazel run @nodejs//:yarn install`. You can pass the options like
-`bazel run @nodejs//:yarn install -- -D `.
-
-Defaults to `True`
-
 
    included_files
    
 
 (*List of strings*): List of file extensions to be included in the npm package targets.
diff --git a/docs/install.html b/docs/install.html
index f152d8653d..d4db6cf114 100755
--- a/docs/install.html
+++ b/docs/install.html
@@ -187,8 +187,8 @@ 
    Custom installation
    
 
    load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
 http_archive(
     name = "build_bazel_rules_nodejs",
-    sha256 = "290b659e7a6323e442db922175a4838e4ac622509f9e9fa0dd16b7ca30377d68",
-    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/3.0.0-rc.0/rules_nodejs-3.0.0-rc.0.tar.gz"],
+    sha256 = "f2194102720e662dbf193546585d705e645314319554c6ce7e47d8b59f459e9c",
+    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/2.2.2/rules_nodejs-2.2.2.tar.gz"],
 )
 
 load("@build_bazel_rules_nodejs//:index.bzl", "node_repositories")