`wrangler dev` incorrectly recognizes `default` as named entrypoint

[774u64]

What versions & operating system are you using?

Wrangler 4.18.0, Node.js v22.15.0, Debian

Please provide a link to a minimal reproduction

https://github.com/774u64/workers-sdk-bug-report

Describe the Bug

When using this workaround to avoid wrangler types generating empty Fetcher types¹, wrangler dev incorrectly interprets default as a named entrypoint and aborts with No such named entrypoint runtime error.

wrangler dev -c worker-a/wrangler.jsonc -c worker-b/wrangler.jsonc

worker-a has access to the following bindings:
Binding                                Resource      
env.MY_SERVICE (worker-b#default)      Worker      

❓ Your types might be out of date. Re-run `wrangler types` to ensure your types are correct.
❓ Your types might be out of date. Re-run `wrangler types` to ensure your types are correct.
⎔ Starting local server...
[wrangler:info] Ready on http://localhost:8787
✘ [ERROR] Worker "core:user:worker-a"'s binding "MY_SERVICE" refers to service "core:user:worker-b" with a named entrypoint "default", but "core:user:worker-b" has no such named entrypoint.



✘ [ERROR] The Workers runtime failed to start. There is likely additional logging output above.

{
	"$schema": "node_modules/wrangler/config-schema.json",
	"name": "worker-a",
	"main": "src/index.ts",
	"compatibility_date": "2025-05-29",
	"observability": {
		"enabled": true
	},

	"services": [
		// With no `entrypoint` property specified, `wrangler types` generates an empty Fetcher type.
		// { "binding": "MY_SERVICE", "service": "worker-b" },
		
		// With `entrypoint` property specified with `default`, `wrangler dev` aborts with a runtime error for "No such named entrypoint".
		{ "binding": "MY_SERVICE", "service": "worker-b", "entrypoint": "default" }
	]
}

Please provide any relevant error logs

Generated worker-configuration.d.ts and logs from wrangler dev -c worker-a/wrangler.jsonc -c worker-b/wrangler.jsonc:

• wrangler.jsonc with default entrypoint
• wrangler.jsonc without default entrypoint

Footnotes

1. Hope this can help: the cause of this workaround is possibly because this line finds for an undefined export when no entrypoint is specified. ↩

[CarmenPopoviciu]

hey @774u64 ,

Unfortunately the workaround described in the docs you linked to, doesn't really fix the problem, but rather results in the behaviour you're seeing right now :/. At the moment generating types for default entrypoints does not work as expected, and we are aware of that. I'll add this issue to our backlog so that we can link to it when a fix is ready.

In the meanwhile I'll make sure to update our docs to correctly reflect the state of the world

🙏 🧡

[CarmenPopoviciu]

cc @emily-shen

[774u64]

@CarmenPopoviciu Thanks for the clarification! Appreciate adding this to the backlog -- looking forward to the fix when it's ready.
Updating the docs sounds great and will definitely help others avoid confusion.

Let me know if there's anything I can do to assist or test things on my end.

[emily-shen]

Hi, really sorry the docs for this were previously incorrect - they've been updated now.

For now, if you can use named entrypoints and that will work correctly with type generation and wrangler dev (unfortunately, not vite though). Otherwise, we've identified how to fix this and will hopefully have a fix PR up soon. This issue is the same as #9229, so I'm going to close this one and we'll followup in that issue when things are fixed. Sorry again about this!