fix(types): remove need for dom.iterable, dom, lib

[wooorm-arcjet]

This commit changes our code to work with @types/node 18 through to the 24, with and without dom, dom.iterable. Things should work in other runtimes, with the correct types for them, but that is difficult to verify as we use Node so much in our build to make sure things work.

It’s been about 5 year of no movement on adding WebAssembly types to Node (https://redirect.github.com/microsoft/TypeScript-DOM-lib-generator/issues/826). We do not expose these types to users, so we can also inline the small API surface we need.

The types of Headers are a bit different in undici (used in @types/node) and the DOM. I don’t know why. I refactored the code, to use properties instead of functions, and to call super methods through Headers.prototype.*.call. An esoteric difference. Someone subclassing and overwriting our types would have to do it similarly slightly differently too. But well, they should not use ArcjetHeaders if they are going to overwrite things, they could use Headers just as well.

The changes except for Headers do not turn up in generated .d.ts files, so should not affect users.

Importantly, there is a weird typescript thing (bug?) which will generate import('undici-types).Headers or import('undici-types).Response or so if return types are inferred.
This was noticeable in nosecone and nosecone-next.
That’s bad because we want users to choose where Headers, Response, etcetera are defined.
The simple solution is to write return types.
I do believe that libraries (not apps) should have explicit return types, as explicit contracts for what the API is, so I think that’s good anyway.

Closes GH-16.

[trunk-io]

😎 Merged successfully - details.

[blaine-arcjet]

This is slick! I need to think about it some more before approval but had a question about the lib check in the meantime.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	undici-types@​7.8.0 ⏵ 7.15.0			+1

View full report

[wooorm-arcjet]

I am not entirely sure why the bun-types use undici-types, but do not declare it as a dependency. Added it, to make things work for us in our tests. Our users do not get bun-types through us, so this should not affect them.