Was this change because it was defined as any type?

Yep

Would this potentially cause problems for folks who've provided a shim for authClient, like this:

// Use the consumer client to define storageOptions and create a GCS object.
const storageOptions = {
  projectId: 'my_project_id',
  authClient: {
    sign: () => Promise.reject('unsupported'),
    getCredentials: () => Promise.reject(),
    request: (opts, callback) => {
      return oauth2Client.request(opts, callback);
    },
    authorizeRequest: async (opts) => {
      opts = opts || {};
      const url = opts.url || opts.uri;
      const headers = await oauth2Client.getRequestHeaders(url);
      opts.headers = Object.assign(opts.headers || {}, headers);
      return opts;
    },
  },
};

Wondering if it changes the function signature if anyone has attempted doing this in TypeScript?

Good point - I reverted this change with a generic <T> (without the any)

Is the buffer re-allocated for each chunk?

Yes, from upstream.
Buffer.alloc(0) creates a "Fast" buffer: https://github.com/nodejs/node/blob/e4aa575b05fcf560c6b77b0fa5036328a3417442/lib/buffer.js#L359-L366

Okay-- just asking because I know in some languages repeated buffer allocs can be painful. Is there anyway to create one buffer and reuse it for each chunk? Or is that not really how it works in node?

Understandable - it doesn't really work that way in Node.js (at least for Buffer.alloc(0))

Would this potentially cause problems for folks who've provided a shim for authClient, like this:

// Use the consumer client to define storageOptions and create a GCS object.
const storageOptions = {
  projectId: 'my_project_id',
  authClient: {
    sign: () => Promise.reject('unsupported'),
    getCredentials: () => Promise.reject(),
    request: (opts, callback) => {
      return oauth2Client.request(opts, callback);
    },
    authorizeRequest: async (opts) => {
      opts = opts || {};
      const url = opts.url || opts.uri;
      const headers = await oauth2Client.getRequestHeaders(url);
      opts.headers = Object.assign(opts.headers || {}, headers);
      return opts;
    },
  },
};

Wondering if it changes the function signature if anyone has attempted doing this in TypeScript?

Is this edge case likely to happen? and what would have happened in the previous implementation of gcs-resumbable-upload?

If this is an optimization, it might be nice to do this in follow up work just to simplify this PR.

This preserves existing behavior - I don't think this is likely to happen (https://github.com/googleapis/gcs-resumable-upload/blob/main/src/index.ts#L577-L596)

I appreciate how thorough these tests are 🎉

It looks like the logic of continueUploading hasn't changed much. Is the upload endpoint a constant URI, and it's just Content-Range that changes to support multiple chunk uploads?

Correct - it's mainly Content-Range and supporting N requests per Upload (required a lot of decoupling throughout the class)

There are a few places like this, where we have almost completely different logic for chunk upload, vs., regular upload, but share a method.

It makes me wonder if the implementation would read slightly cleaner if we had, export class Upload extends Pumpify in index.ts, as it is today, but then introduced an additional class, export class ChunkUpload extends Upload.

It might introduce a bit of repeated logic, but I'm curious if it would make the implementation even more elegant.

+1, I think separating out the logic more between the two upload types would definitely make the code easier to read.

Good point - I figured after the refactor to support multiple requests most of the logic would be the same with the exception of 1 parameter (upstreamIterator in startUploading) and 3 if statements (including this one).

I was hoping shouldContinueWithNextMultiChunkRequest would make it easier to understand what's happening, but seemed to have backfired.

As I said, not blocking for me, but if you have the time to experiment with the refactor, I'd be curoius what it looks like.