Should the Dynamic Worker Loader API validate the WorkerCode object passed to it?

[irvinebroque]

You can add any arbitrary key onto the WorkerCode object that gets passed into the Dynamic Worker loader API, and the runtime will ignore nonsense / unused keys on the object, ex blarg:

		const worker = env.LOADER.get('some-id-you-define', () => {
			return {
				compatibilityDate: "2025-06-01", 
				mainModule: "index.js",
				modules: {
					"index.js": untrustedCode
				},
				blarg: "blarg",
				env: {
					// Provide the untrusted code with a custom API
					CUSTOM_BINDING_API: ctx.exports.Greeter({ props : { greeting: 'Hello' }}),
					// Provide the untrusted code with any environment variables
					USERNAME: 'brendan'
				}
			};
		});

...and things will still work and run.

But this means that working with an LLM who doesn't know the dynamic Worker loader API, it will make things up — ex: I was working with Claude Code and it just invented there being a bindings key on this object, and tried passing in bindings in the same shape as bindings from wrangler.jsonc

The net impact of this was that I saw an error in the dynamic Worker because of a missing object on env — which was a less direct place for the error to occur. I'd have wanted this to fail earlier, loudly, and be clear — what you passed into the Worker loader isn't valid

I wonder if we should be validating input arguments, and throwing a loud error if you add things onto this object that aren't valid? Maybe this is too restrictive but hitting this made me think about implications of LLMs intersecting with new APIs. This was even with me feeding Claude the Worker Loader API docs, which really surprised me.

@dinasaur404 @kentonv for thoughts

[kentonv]

This should be a TypeScript error. It should be possible to feed TypeScript errors back to Claude, in which case it should be able to figure this out.

Traditionally, though, unknown options are not a runtime error. There's a lot of precedent for this in standard APIs. Technically this API is not standard, so we could do something different, but deviating from standard patterns would require special support in JSG and might just cause different confusion.