We should error when a user tries to implement a durable object in a worker using the service-worker format

[caass]

From @Electroid:

There is a little more nuance: modules are required to implement a Durable Object, but not to bind to one. Therefore, it’s only an error when the format is service worker and the Durable Object binding does not have a “script_name”.

I tried a quick implementation (#634) but actually I think this is maybe more complex than a simple fix like that.

We currently guess the worker format by checking for exports in the bundled code generated by esbuild. If there are no exports, then the worker is service-worker format. If there are some, it's a module worker.

The issue I'm running into is that a Durable Object implementation will contain an export, necessarily. So checking for the existence of exports is kind of not enough to cover this case, cause what if the user writes code like the following:

export class DurableObjectExample {
    constructor(state, env) {
    }

    async fetch(request) {
        return new Response('Hello World');
    }

}

// omitted: wrangler.toml binds DurableObjectExample as EXAMPLE_DO

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  // env is just set up as a global in service workers
  const id = EXAMPLE_DO.idFromName(request.url);
  const stub = EXAMPLE_DO.get(id);
  return stub.fetch(request);
}

Edit:

I have been informed that by virtue of having an export statement, this code is actually an ESModule, and will error with "no default export" or some such when attempting to publish. So it's actually reasonable to keep the current logic, and just check if there's a script_name as Ashcon suggested.