🚀 Feature Request: RPC support in `wrangler types` across multiple scripts

[helloimalastair]

Describe the solution

Would it be possible to get the wrangler types command to generate proper types for RPC-enabled bindings, when binding to a Worker/DO that is defined in a different script?
For example, Durable Object bindings pointing to a different script are always typed as

interface Env {
	DO_BINDING: DurableObjectNamespace;  /* MyDOClass from some-other-worker */;
}

which means that you cannot call any RPC methods on DO_BINDING stubs. Instead, it could be output as

interface Env {
	DO_BINDING: DurableObjectNamespace<import("../../apps/other-worker/src/index").MyDOClass>;
}

This would require a bit of work for determining the location of multiple Workers at once, and would not work when you do not have the source for all of your Workers.

[CarmenPopoviciu]

cc @andyjessop

[threepointone]

I belive wrangler types does use the type of the class now, so rpc should just work

eg: https://twitter.com/naporin24690/status/1824107980872376642

[threepointone]

We shouldn't be putting undefined though, do you have a repro where that happens?

[helloimalastair]

Ooh, that's why... I was looking in a Pages Project that bound to a DO defined in a separate Worker... The Worker itself does have the correct types.

Would it be possible to generate types across multiple Workers/Pages projects, assuming that you have a reference to the source of them all available locally?

[threepointone]

Yeah if we had a reference to the source it'll be straightforward to generate the type

We should definitely not generate <undefined> there, that seems like a bug anyway

[helloimalastair]

Oh, that's cool, I see in a comment that it does recognize the originating Worker. So it would just need a way to define multiple Workers that it could locate...

Also, my mistake on the <undefined> part. It was based on the default param DurableObjectNamespace, which is undefined, but the actual Env type has no param at all...

Sorry about that!

[alexanderniebuhr]

We are facing a similar issue. wrangler types always resets the types in worker-configuration.d.ts to RPC: Fetcher, while I would like to see something like Service<import('../orm/src/index').ORM>
I'm not sure if that is even possible, because that would mean wrangler needs to understand project and file-structure, but this is a really crucial missing piece in the great DX story. Our team doesn't want to maintan types manually, since we have multiple workers, which need to be updated in case something changes. Does this work for anyone? Or does anyone have a good idea for an workaround?

[a-type]

We are facing a similar issue. wrangler types always resets the types in worker-configuration.d.ts to RPC: Fetcher, while I would like to see something like Service<import('../orm/src/index').ORM> I'm not sure if that is even possible, because that would mean wrangler needs to understand project and file-structure, but this is a really crucial missing piece in the great DX story. Our team doesn't want to maintan types manually, since we have multiple workers, which need to be updated in case something changes. Does this work for anyone? Or does anyone have a good idea for an workaround?

Commenting as this is also a significant limitation for me which makes the old typings feel less fiddly, even if they're more manual work.

I feel this could be solved with a metadata field in the wrangler config for each service binding which optionally provides a module name to import the class from -- e.g. ../orm/src/index or, in a monorepo, @my-project/service-orm, etc. This could be verbatim written to import('...').WorkerClass in the typings.