feat: add ModuleWorker type definitions

[lukeed]

We're currently missing typedefs for creating module workers, so I included some that allow for strict-mode TS usage.

The ModuleWorker generic optionally accepts a typed Bindings interface, which will propagate to any fetch/scheduled handlers on the definition.

Included a strictly-typed module worker in the test.ts file, which makes use of the generic.

And then here's an example module worker, without any specific env typing, that is completely valid too:

// worker.ts
const worker: ModuleWorker = {
  fetch(req, env, ctx) {
    return new Response('OK');
  }
}

export default worker;

[lukeed]

Explicitly defining all bindings that the worker (below) will have access to.
It extends the ModuleWorker.Bindings interface for strictness within the generic itself, but also to prevent a user from accidentally declaring an invalid value type – like FOO: number

[lukeed]

Define the ModuleWorker, passing thru the Env interface as the generic's type argument.

Doing this allows for strict type checks (and auto-complete) for all env parameter usage throughout the worker.

[lukeed]

Not shown is the ability to define handler functions individually while still maintaining strict typing. This is because each handler definition is, itself, a generic:

// src/handlers.ts
export const fetcher: ModuleWorker.FetchHandler<Env> = async function (req, env, ctx) {
  // the `env` is strictly typed
  return new Response('OK');
}

// src/index.ts
import { fetcher } from './handlers';
export default { fetch: fetcher };

[GregBrimble]

Fixes #76

[GregBrimble]

Yeah, lovely to get this in now. Thanks @lukeed! :)

[tylerbrostrom]

Hey this is great! What needs to happen to get this merged?

[mrbbot]

#112 has now been merged, which includes an ExportedHandler<Env> interface that behaves like ModuleWorker in this PR. It doesn't have the same restrictions on what bindings can look like though. Might want to update...

workers-types/overrides/events.d.ts

Line 26 in 61c5989

interface ExportedHandler<Env = unknown> {

...for that.

[maraisr]

When can we get this one merged?

[mrbbot]

@maraisr You can use the ExportedHandler<Env> interface in version 3.0.0 exactly like the ModuleWorker<Env> in this PR. 👍 We probably ought to close this PR, unless we want to add the same restrictions on what bindings can look like.

[lukeed]

Yup it's the same, can alias it & bring the strict types too if you want

type Bindings = Record<string, KVNamespace | DurableObjectNamespace | string>;
type ModuleWorker<Env extends Bindings = Bindings> = ExportedHandler<Env>;

[maraisr]

Just a shame, the ergonomics about importing and defining a ModuleWorker just feels way more natural, than ExportsHandler. Not sure that'll be anybodys understanding of that type.

In any case, glad there's been efforts in this space!