The same job, the other language

Give the TypeScript side the same improvement the Go side got:

import { capitalCase } from 'change-case';

export function greet(name: string): string {
  return `Hello ${capitalCase(name)}`;
}

Declare it the ordinary way:

{
  "name": "greet",
  "private": true,
  "dependencies": {
    "change-case": "5.4.4"
  }
}

Then generate a lockfile with your package manager, exactly as you would in any project. That lockfile — not the manifest — is what the build reads:

module(name = "greet")

# Go.
bazel_dep(name = "rules_go", version = "0.61.1")

go_sdk = use_extension("@rules_go//go:extensions.bzl", "go_sdk")
go_sdk.download(version = "1.26.5")

# TypeScript. rules_ts needs a compiler version, which is the chapter's
# point in miniature: the compiler is an input too.
bazel_dep(name = "aspect_rules_js", version = "3.2.2")
bazel_dep(name = "aspect_rules_ts", version = "3.8.11")
bazel_dep(name = "rules_nodejs", version = "6.7.4")

node = use_extension("@rules_nodejs//nodejs:extensions.bzl", "node")
node.toolchain(node_version = "22.22.2")

rules_ts_ext = use_extension("@aspect_rules_ts//ts:extensions.bzl", "ext")
rules_ts_ext.deps(ts_version = "5.9.3")
use_repo(rules_ts_ext, "npm_typescript")

# Build-file generation for Go.
bazel_dep(name = "gazelle", version = "0.51.3")

# Third-party Go modules come from go.mod. The extension reads it and
# creates one repository per module; use_repo names the ones the build
# actually depends on.
go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_mod = "//:go.mod")
use_repo(go_deps, "org_golang_x_text")

# npm packages come from the pnpm lockfile, which stays the source of
# truth. The extension turns it into one repository per package.
npm = use_extension("@aspect_rules_js//npm:extensions.bzl", "npm")
npm.npm_translate_lock(
    name = "npm",
    pnpm_lock = "//:pnpm-lock.yaml",
    verify_node_modules_ignored = "//:.bazelignore",
)
use_repo(npm, "npm")

The first failure

Build, and nothing builds:

$ bazel build //web/...
ERROR: pnpm 'allowBuilds' (or 'onlyBuiltDependencies' in pnpm < 10.26)
configuration required.
Packages that rules_js should generate lifecycle hook actions for must
be declared in 'allowBuilds' or 'onlyBuiltDependencies'.

Here is what that is about, and it is the best thing in this chapter.

Installing an npm package can run arbitrary code on your machine. Packages declare install scripts, and package managers run them — that is the design, and it is how a native module gets compiled during installation. It is also, occasionally, how a compromised package gets its foothold.

The build will not run any of them until you say which ones may. Not a warning, not a prompt: a refusal.

For this project, the answer is that none of them need to:

packages: []

# Installing a package can run arbitrary code through its lifecycle
# hooks. The build refuses to run any unless it is named here — an
# empty list means none, which is what this project wants.
onlyBuiltDependencies: []

Packages are labels

With the policy declared, the build proceeds. Look at how the dependency is written:

load("@aspect_rules_ts//ts:defs.bzl", "ts_project")

ts_project(
    name = "greeting",
    srcs = ["greeting.ts"],
    declaration = True,
    transpiler = "tsc",
    tsconfig = "//web:tsconfig",
    visibility = ["//web:__subpackages__"],
    # npm packages are labels in your own workspace, not bare names.
    deps = ["//:node_modules/change-case"],
)

That is the most unfamiliar idea in this chapter. There is no implicit resolution against a directory somewhere up the tree. A target at the workspace root turns every package in the lockfile into a label:

load("@gazelle//:def.bzl", "gazelle")
load("@npm//:defs.bzl", "npm_link_all_packages")

# gazelle:prefix example.com/greet
gazelle(name = "gazelle")

# Creates the //:node_modules/* labels the TypeScript targets depend on.
npm_link_all_packages(name = "node_modules")

Once you see it, the consistency is the point. A third-party package is a target with a name, and your code depends on it the same way it depends on your own library — which is why chapter three's rdeps works across the boundary, and why a package bump invalidates exactly the targets that use it.

The second failure

Now run it the way you have been running it since chapter two:

$ node bazel-bin/web/greet.js
Error: Cannot find module 'change-case'

Nothing is broken. The emitted file is correct, and the package exists in the build. What is missing is the runfiles tree — the directory layout a program needs at runtime, which the build knows how to construct and bare node knows nothing about.

Declare a binary and the build assembles it:

load("@aspect_rules_js//js:defs.bzl", "js_binary")
load("@aspect_rules_ts//ts:defs.bzl", "ts_config", "ts_project")

ts_config(
    name = "tsconfig",
    src = "tsconfig.json",
    visibility = ["//web:__subpackages__"],
)

ts_project(
    name = "web",
    srcs = ["greet.ts"],
    declaration = True,
    transpiler = "tsc",
    tsconfig = ":tsconfig",
    deps = ["//web/greeting"],
)

# Running the emitted file with node directly cannot resolve npm
# packages. A js_binary builds the runfiles tree that can.
js_binary(
    name = "greet",
    data = [":web"],
    entry_point = "greet.js",
)

$ bazel run //web:greet
Hello World

Both languages now print the same thing, and both got there through a library neither of us wrote.

What the lockfile is really holding

The lifecycle-hook policy is about code that runs during installation. There is a second guarantee underneath it, about the bytes themselves.

Look at what the lockfile actually records for a package:

change-case@5.4.4:
  resolution:
    integrity: sha512-HRQyTk2/YPEkt9TnUPbOpr64Uw3KOicFWPVBb+xiHvd6...

That hash is the pin. The version number is a name the registry controls; the hash is a fact about the contents, and it is what makes "the same dependency" mean something.

To see it working, corrupt it — change one character, as a registry serving different bytes than it served last week would effectively do:

$ bazel build //web/...
WARNING: Download from https://registry.npmjs.org/change-case/-/change-case-5.4.4.tgz
  failed: Checksum was sha512-HRQyTk2/... but wanted sha512-AAAyTk2/...
ERROR: no such package '@@...npm__change-case__5.4.4//'

The build fetched the package, hashed it, compared it against the lockfile, and refused to use it. Nothing was installed and no code from that archive ran — the check happens before the archive is unpacked, which is the only order that helps.

This is the same idea as chapter four's sandbox, one layer out. There, a step could not read a file nobody declared. Here, a build cannot use an archive whose contents nobody vouched for. Both are the through-line applied to a place where the answer had previously been "trust whatever showed up."

Why this half is harder

It is fair to notice that Go took four lines and this took three failures. Some of that is incidental — version skew in a key name is nobody's design.

But the substantive part is that JavaScript packaging carries more ambiguity for the build to pin down. A package's dependencies can be hoisted, its install scripts can run code, its entry point can be resolved several ways at runtime. Each of those is a place where "what did this step actually read" has historically been answered by convention. Making the answer explicit is more work here because there was more left implicit.

Try this in your own repository

Find out which of your dependencies run install scripts. Most package managers can list them. For each, decide whether it needs to — and notice how few of the answers you can give confidently, on packages you have been installing for years.

Check that your integrity hashes are actually checked. Corrupt one in a scratch branch and see whether anything complains. A lockfile whose hashes nothing verifies is documentation, not a control.

What you can now do

Add an npm package to a build, explain the lifecycle-hook policy to a colleague who has never been asked about it, and run emitted JavaScript that depends on packages. Both languages now reach outside — and your module file has grown long enough to be worth reorganizing, which is the next chapter.