> ## Documentation Index
> Fetch the complete documentation index at: https://site.aspect.build/llms.txt
> Use this file to discover all available pages before exploring further.

# @rules_nodejs//nodejs:toolchain.bzl

> Bazel rules_nodejs toolchain rule nodejs_toolchain defining a Node.js toolchain for a target platform so JavaScript rules can resolve the node binary.

<Callout icon="book">
  Documentation for [@rules\_nodejs@v6.7.3](https://registry.bazel.build/modules/rules_nodejs/6.7.3) -- <Icon icon="github" iconType="brands" /> [View source](https://github.com/bazel-contrib/rules_nodejs/blob/v6.7.3/nodejs/toolchain.bzl)
</Callout>

This module implements the node toolchain rule.

## Function: `nodejs_toolchain`

Defines a node toolchain for a platform.

You can use this to refer to a vendored nodejs binary in your repository,
or even to compile nodejs from sources using rules\_foreign\_cc or other rules.

First, in a BUILD.bazel file, create a nodejs\_toolchain definition:

```python theme={null}
load("@rules_nodejs//nodejs:toolchain.bzl", "nodejs_toolchain")

nodejs_toolchain(
    name = "toolchain",
    node = "//some/path/bin/node",
)
```

Next, declare which execution platforms or target platforms the toolchain should be selected for
based on constraints. A separate toolchain type is used for runtime target platform selection.

```python theme={null}
toolchain(
    name = "my_nodejs",
    exec_compatible_with = [
        "@platforms//os:linux",
        "@platforms//cpu:x86_64",
    ],
    toolchain = ":toolchain",
    toolchain_type = "@rules_nodejs//nodejs:toolchain_type",
)
toolchain(
    name = "my_nodejs_runtime",
    target_compatible_with = [
        "@platforms//os:linux",
        "@platforms//cpu:x86_64",
    ],
    toolchain = ":toolchain",
    toolchain_type = "@rules_nodejs//nodejs:runtime_toolchain_type",
)
```

See [https://bazel.build/extending/toolchains#toolchain-resolution](https://bazel.build/extending/toolchains#toolchain-resolution) for more information on toolchain
resolution.

Finally in your `WORKSPACE`, register it with `register_toolchains("//:my_nodejs")`

For usage see [https://docs.bazel.build/versions/main/toolchains.html#defining-toolchains](https://docs.bazel.build/versions/main/toolchains.html#defining-toolchains).
You can use the `--toolchain_resolution_debug` flag to `bazel` to help diagnose which toolchain is selected.

### Parameters

<ParamField body="name" type="unknown" required>
  Unique name for this target
</ParamField>

<ParamField body="node" type="unknown" default={`None`}>
  Node.js executable
</ParamField>

<ParamField body="node_path" type="unknown" default={`""`}>
  Path to Node.js executable file

  This is typically an absolute path to a non-hermetic Node.js executable.

  Only one of `node` and `node_path` may be set.
</ParamField>

<ParamField body="npm" type="unknown" default={`None`}>
  Npm JavaScript entry point
</ParamField>

<ParamField body="npm_path" type="unknown" default={`""`}>
  Path to npm JavaScript entry point.

  This is typically an absolute path to a non-hermetic npm installation.

  Only one of `npm` and `npm_path` may be set.
</ParamField>

<ParamField body="npm_srcs" type="unknown" default={`[]`}>
  Additional source files required to run npm.

  Not necessary if specifying `npm_path` to a non-hermetic npm installation.
</ParamField>

<ParamField body="headers" type="unknown" default={`None`}>
  cc\_library that contains the Node/v8 header files
</ParamField>

<ParamField body="kwargs" type="unknown">
  Additional parameters
</ParamField>

## Function: `node_toolchain`

Deprecated. Use nodejs\_toolchain instead.

### Parameters

<ParamField body="kwargs" type="unknown">
  Parameters to forward to nodejs\_toolchain rule.
</ParamField>

## Provider: `NodeInfo`

Information about how to invoke Node.js and npm.

### Fields

<ResponseField name="node">
  Node.js executable

  If set, node\_path will not be set.
</ResponseField>

<ResponseField name="node_path">
  Path to Node.js executable; typically an absolute path to a non-hermetic Node.js.

  If set, node will not be set.
</ResponseField>

<ResponseField name="npm">
  Npm JavaScript entry point File

  For backward compability, if set then npm\_path will be set to the runfiles path of npm.
</ResponseField>

<ResponseField name="npm_path">
  Path to npm JavaScript entry point; typically an absolute path to a non-hermetic Node.js.

  For backward compability, npm\_path is set to the runfiles path of npm if npm is set.
</ResponseField>

<ResponseField name="npm_sources">
  Additional source files required to run npm
</ResponseField>

<ResponseField name="headers">
  Optional.
  (struct) Information about the header files, with fields:

  * providers\_map: a dict of string to provider instances. The key should be
    a fully qualified name (e.g. `@rules_foo//bar:baz.bzl#MyInfo`) of the
    provider to uniquely identify its type.

    The following keys are always present:

    * CcInfo: the CcInfo provider instance for the headers.
    * DefaultInfo: the DefaultInfo provider instance for the headers.

    A map is used to allow additional providers from the originating headers
    target (typically a `cc_library`) to be propagated to consumers (directly
    exposing a Target object can cause memory issues and is an anti-pattern).

    When consuming this map, it's suggested to use `providers_map.values()` to
    return all providers; or copy the map and filter out or replace keys as
    appropriate. Note that any keys beginning with `_` (underscore) are
    considered private and should be forward along as-is (this better allows
    e.g. `:current_node_cc_headers` to act as the underlying headers target it
    represents).
</ResponseField>

<ResponseField name="target_tool_path">
  (DEPRECATED) Path to Node.js executable for backward compatibility
</ResponseField>

<ResponseField name="tool_files">
  (DEPRECATED) Alias for \[node] for backward compatibility
</ResponseField>

<ResponseField name="npm_files">
  (DEPRECATED) Alias for npm\_sources.to\_list()
</ResponseField>