Have a fun one for the Workers team...
Have a fun one for the Workers team... itty-router is staged to release as v5, but we're running into an issue with the direct export signature.
Background:
An itty
Router
instance is a Proxy
, with a fetch
method. This matches the expected { fetch }
signature that Cloudflare or Bun expect. However, CF is having issues with the Proxy (Bun is fine with it, for comparison).
5 Replies
So to me, this suggests that CF has an issue with the Proxy, despite
fetch
being a first-class property that even destructures as expected.re: Proxy issue, sounds kinda like https://github.com/cloudflare/workerd/issues/1686
Hmmm
I get a weird weird/diff error than that:
I suspect Cloudflare is checking the export for a particular attribute/signature that's being picked up by the Proxy intercepts (which we use for routing)
so it's likely trying to use something that doesn't exist in the way that CF thinks it might.
This appears to be because CF is attempting to iterate over an expected
{ middleware }
attribute. Is the code that does this open source?
I'd love to PR an explicit check for if middleware
not only exists (as it would in this case), but is, in fact, able to be iterated (e.g. NOT a function).
for example, the following snippet throws the same error:
Should default exports even work?
Isn’t that the established pattern for Workers?
So assuming your router matches the expected { fetch } signature that a Worker index expects, directly exporting the router should be no diff. Hono does this as well.