HeadersInit -> HeadersInitializer

[cloudflare]

HeadersInit -> HeadersInitializer

[jdanyow]

Any chance these name changes could be reverted? They make it difficult for packages targeting both cloudflare workers and service workers.

[lookfirst]

I'd say focus 100% on making standards work so that there is a clean API that end-users of this library can most easily port over other existing standard code. This open issue is a substantial regression.

[lookfirst]

RequestInit -> RequestInitializerDict

[lookfirst]

BodyInit -> BodyInitializer

[Electroid]

Thanks for calling these out. At the very least, I think it would make sense to provide some type aliases that we mark as @deprecated, and point to the new names.

[lookfirst]

Why rename them? They are a worker standard.

Plus, RequestInitializerDict is awful... sounds like a python programmer, or something.

[mrbbot]

Hey! 👋 I agree these types shouldn't be renamed as they are standard. There's an internal reason why they're different though. In the runtime source code these types are generated from, RequestInitializerDict is the name of the standard RequestInit interface, whereas RequestInit is actually defined as a type alias to RequestInitializerDict | Request. This get's inlined here:

workers-types/index.d.ts

Line 705 in 51162f8

constructor(input: Request | string, init?: RequestInitializerDict | Request);

It's the same for ResponseInit, BodyInit and HeadersInit as far as I remember. Obviously this isn't ideal. We should either rename the types in the runtime, or add an additional renaming phase to the end of the auto-generation script that fixes these kind of issues.

[vlovich]

In the latest version we still leak the non-standard names unfortunately. However, as a mitigation I've reintroduced the standard names as aliases to ease porting issues hopefully (#120). Unfortunately it would be annoying to try to figure out how to get rid of those internal names with our automated type generation vs just fixing the name in the runtime.

If you're still having problems, please reopen or file a new issue. Sorry for the churn this may have caused.

[lookfirst]

It would be nice if there were unit tests or at least a sample project that depends on the "standard" values so that this doesn't become an issue again.

[vlovich]

That's a good idea and an area for constant improvement. I'm on the runtime team and was just updating some of the automation pieces and my background is primarily C++/python. I personally unfortunately don't have time/experience to add tests for some of these issues but I'd be happy to review such contributions.