fix: Handle cloudflare-internal:workers default export

[penalosa]

When running as a workerd extension module (like miniflare's dispatch-namespace.worker.ts), only cloudflare-internal:workers is available, rather than cloudflare:workers. It's easy enough for Miniflare to rewrite the capnpweb imports to cloudflare-internal:workers when bundling it's internal workers, but the import * approach causes problems, since the internal module exports everything on default rather than as named exports:

// cloudflare:workers (regular workers)
import * as cfw from "cloudflare:workers";
cfw.RpcTarget // ✅ works

// cloudflare-internal:workers (extension modules)
import * as cfw from "cloudflare-internal:workers";
cfw.RpcTarget // ❌ undefined
cfw.default.RpcTarget // ✅ works

This change normalizes workersModule to handle both cases by checking for a default export first.

[changeset-bot]

🦋 Changeset detected

Latest commit: 29263e1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@139

commit: 29263e1

[penalosa]

I have read the CLA Document and I hereby sign the CLA

[petebacondarwin]

Is there a chance that this breaks modules that previously had a minimal default export but really wanted to share most exports via named exports?

[petebacondarwin]

Oh I see this is explicitly the cloudflare:workers module.
I thought this was generic code for any module.
How does that work for cloudflare:workers-internal then?

[kentonv]

I'm uncomfortable with this fix as it means that if cloudflare:workers would never be able to add a default export without breaking Cap'n Web users in the wild. We cannot force-update Cap'n Web so we would not be able to fix it on the Cap'n Web side.

Moreover, it's unclear that this is a lasting fix as there could be further differences between cloudflare-internal:workers and cloudflare:workers that may only reveal themselves in the future when Cap'n Web tries to use more of the cloudflare:workers interface.

IMO the problem here is a problem with workerd extension modules, they should be allowed to import cloudflare:workers. This seems like an important thing to fix in general as it is increasingly the case that you need to import cloudflare:workers to properly implement a lot of things.

[penalosa]

@kentonv fair enough—I'll close this and try and see if I can open a PR to workerd