chore(deps): bump @types/node from 25.3.5 to 26.4.1

[dependabot]

Bumps @types/node from 25.3.5 to 26.4.1.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[mozilla-blender]

Reviewing this major version bump. Workflow run

[mozilla-blender]

BLEnder picked up this PR. Workflow run

[mozilla-blender]

NEEDS_REVIEW: this major version bump needs code-owner review

Confidence: high
Reason: Reproduced a real, bump-caused type error locally. @types/node v26 widens crypto.BinaryLike to include ArrayBuffer, but Hash.update() still only accepts 'string | ArrayBufferView'. src/utils/fxa.ts:230 passes a crypto.BinaryLike straight into createHash('sha1').update(), which no longer typechecks: 'error TS2345: Argument of type BinaryLike is not assignable to parameter of type string | ArrayBufferView'. Confirmed the regression is new by installing @types/node@25.3.5 side by side, where the type is 'type BinaryLike = string | NodeJS.ArrayBufferView' -- assignable, hence no error on the old version. This matches the three red CI checks: the npm-lint job runs 'tsc -p tsconfig.json --noEmit', and npm-build / Build Docker image compile the same sources. The affected function getSha1 is explicitly excluded from coverage ('/* c8 ignore next 3 */' plus a 'TODO: Add unit test when changing this code' comment), so no test would catch a behavioural change either. Separately, the package pins engines.node '20.20.x' and Dockerfile 'node:20.20-alpine', so this moves type definitions six majors ahead of the runtime actually deployed. Not auto-mergeable without a code change (narrow the getSha1 parameter to 'string | NodeJS.ArrayBufferView', or normalise ArrayBuffer input via Buffer.from before .update()).

Breaking changes: crypto.BinaryLike widened from 'string | NodeJS.ArrayBufferView' (25.3.5) to additionally include 'ArrayBuffer' (26.4.1), while Hash/Hmac .update() still accepts only 'string | ArrayBufferView' -- BinaryLike is therefore no longer assignable to .update(); ArrayBufferView type references became generic ('ArrayBufferView'), tightening assignability for any code passing raw ArrayBuffer into Node crypto/stream APIs; Type definitions now describe the Node 26 API surface while this project pins engines.node '20.20.x' and builds on node:20.20-alpine, so types may advertise globals and APIs absent from the deployed runtime; Bundled undici-types dependency moved to ~8.3.0, which can shift fetch/Response/Request/Headers typings that overlap with the DOM lib enabled in tsconfig ('lib': ['dom', 'dom.iterable', 'esnext'])
Affected code: src/utils/fxa.ts:229-231 -- function getSha1(email: crypto.BinaryLike) { return crypto.createHash('sha1').update(email).digest('hex'); } -- fails to compile with TS2345; package.json 'lint' script ('tsc -p tsconfig.json --noEmit') -- the npm-lint CI job, currently failing; npm-build and Build Docker image CI jobs -- compile the same sources, currently failing; tsconfig.json -- 'types'/'typeRoots' are commented out so @types/node is resolved ambiently across the whole program; 'skipLibCheck': true hides errors inside .d.ts files but not at callsites like fxa.ts
Test coverage: No coverage for the one broken callsite. getSha1 in src/utils/fxa.ts carries an explicit '/* c8 ignore next 3 */' directive and an inline 'TODO: Add unit test when changing this code' comment, so it is deliberately excluded from the vitest/c8 suite. Consistent with that, the unit-tests, test-integrations and functional-tests CI jobs all pass while npm-lint and npm-build fail -- the runtime suites cannot detect this class of regression because @types/node is compile-time only. The breakage is caught solely by the typechecker, and the typechecker is red. Note: a full repo-wide sweep of other Node built-in API usage could not be completed (the search subagent was blocked by a bwrap sandbox failure), but the complete 'tsc --noEmit' run over the whole program is a strict superset of that sweep and surfaced exactly one @types/node-attributable error; the remaining errors in the run were missing generated modules (src/telemetry/generated/**) and Next.js PageProps/LayoutProps globals, both artifacts of running tsc without the preceding 'build-glean', 'build-nimbus' and 'next typegen' codegen steps, and unrelated to this bump.

[mozilla-blender]

Reviewing this major version bump. Workflow run

[mozilla-blender]

BLEnder picked up this PR. Workflow run

[mozilla-blender]

Reviewing this major version bump. Workflow run