chore: bump @types/node from 22.19.17 to 26.2.0

[dependabot]

Bumps @types/node from 22.19.17 to 26.2.0.

Commits

• See full diff in compare view

[claude]

Claude finished @dependabot[bot]'s task in 3m 30s —— View job

---

Dependency review: @types/node 22.19.17 → 26.2.0

• Read the PR diff
• Check semver / major-version implications
• Check how @types/node is used (tsconfig, engines, CI Node versions)
• Verify build + tests
• Post review

Verdict: safe to merge. One thing worth a deliberate decision (inline comment on package.json:43), no blockers.

What changed

Four majors, 22 → 26, plus a transitive undici-types 6.21 → 8.3. Both are dev-only and types-only — no runtime code ships from either. The lockfile also gained license/bin/engines on the root entry; that's npm re-normalizing metadata that was missing from the old lockfile, not something Dependabot introduced.

Risks I actually checked

1. Type/runtime skew — the only real finding. package.json:13 declares engines: node >=20 and ci.yml builds on Node 20, but the types now describe Node 26. Nothing in src/ uses a post-20 API (process.env, process.exit, and global fetch/FormData/Blob are the entire Node surface), so nothing breaks — but tsc stops being a guard against future use of a Node 21–26-only API, which would then fail at runtime on the minimum supported version. Details inline. Fix this →

2. undici-types 8.x is the highest-signal surface here. tsconfig.json sets no lib, so the global fetch/Response/RequestInit/Headers/FormData/Blob types all come from @types/node → undici-types. That is exactly what src/client/kosli-client.ts is built on (FetchFn = typeof globalThis.fetch at line 22, RequestInit at line 99, buildFormData at line 39, response.json() at lines 159/172). The await response.json() result is cast through as Record<string, string> at line 160, so a Promise<unknown> return signature is already handled. Build is green, so no tightening in v8 bit us.

3. TypeScript compat. typescript resolves to 5.9.3 in the lockfile — comfortably inside DefinitelyTyped's support window for @types/node 26. strict: true, NodeNext, and the .js-extension convention are untouched.

4. Verification. I could not npm install in this sandbox, so I did not run tsc/vitest locally. Relying on the PR's own CI run, which is green on Node 20 (build + tests + .mcpb smoke test).

Follow-up worth considering (pre-existing, not from this PR)

tsconfig.json has include: ["src"] and exclude: [..., "test"], so npm run build typechecks neither test/ nor scripts/, and vitest doesn't typecheck either. That matters specifically for a types bump: the FormData/Blob assertions in test/client/kosli-client.test.ts:211-256 and node:fs/node:url imports in scripts/generate-catalog.ts are outside the compiler's view, so a green CI proves less about a @types/node major than it looks like it does. A typecheck script over the whole repo (tsc --noEmit -p tsconfig.typecheck.json) would close that gap and make future @types/node bumps genuinely self-verifying. Fix this →
· dependabot/npm_and_yarn/types/node-26.2.0

[claude]

Type/runtime skew worth a conscious decision: this package declares "engines": { "node": ">=20" } (line 13) and ci.yml builds on Node 20, but the type definitions now describe Node 26.

Nothing in src/ uses a post-20 API today (process.env, process.exit, and the global fetch/FormData/Blob), so this is not a breakage — but tsc will no longer reject a Node 21–26-only API if one gets added later, and it would fail at runtime on the minimum supported Node. The conventional fix is to keep @types/node at the lowest supported runtime major (^20) rather than the newest.

Either pin back to ^20 or raise engines to match — but don't leave the two four majors apart silently.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.