You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(types): remove need for dom.iterable, dom, lib (#5047)
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.
ClosesGH-16.
0 commit comments