Could you avoid making the result of type Response as that leaks the underlying transport layer. You already expose image as a readable stream which is perfect. Do we need to expose more?

This is just a convenience that does:

new Response(this.image(), {
      headers: {
        "content-type": this.contentType(),
      },
    });

so I don't think it leaks anything, but happy to remove it if you don't think it's useful

I wonder if there is a precedence for error handling in bindings. It seems that R2 and D1 as preexisting APIs take vastly different approach to this.

Could we think about which way we want to go in this area, and start consolidating the error APIs to feel consistent?

at minimum this property should be readonly. For reference this is what R2Error looks like:

declare interface R2Error extends Error {
  readonly name: string;
  readonly code: number;
  readonly message: string;
  readonly action: string;
  readonly stack: any;
}

source: https://unpkg.com/browse/@cloudflare/workers-types@4.20240614.0/experimental/index.d.ts

Made it this for now:

interface ImagesError extends Error {
  readonly code: number;
  readonly message: string;
  readonly stack?: string;
}

It's fairly similar to the Vectorize error (which I cribbed from shamelessly)

could the input be a stream instead? It's easy to turn a blob to a stream, the opposite is problematic.

my main goal here is to enable streaming transformations/use-cases by default, because enabling that ad-hoc will be hard/awkward.

I've made the interfaces take streams and then buffer internally for now as it's a bit tricky to stream properly with multipart, which is what the backend uses

Worth measuring but in theory it would be more efficient to avoid bouncing back and forth between C++ and JS:

Made this change, also much more obviously correct which is a plus for me!