In practice, I don't think we can support this use case at runtime anyway.

If someone passes us a complete StandardSchema schema from another library, we'll be able to use it as-is (try block).

For us to be able to extend the built-in SqsRecordSchema however we must receive a Zod schema or both the extend and JSONStringified will fail at runtime - so the type error is correct here.

With this in mind, we might want to use the vendor key on the schema (see spec) to check if it's a Zod schema and throw either 1/ throw an error or 2/ log a warning and ignore parsing if the schema is from another library we can't extend with.

If instead we find this conditional behavior confusing, we'll have to restrict the type of schema to Zod schemas only.

I'm in favour of throwing here, if we just log a warning them we run the risk of passing on invalid events.

Both throwing an error and continue processing an invalid event would result in the item being marked as failed by the Batch Processor and sent back to the source.

Most likely we should also log a warning, otherwise all operators would see is the item being reprocessed and eventually be sent to a DLQ or lost.

Yeah, that's a good point, it will be much easier to diagnose if we emit a log statement.

In order to cast the schema to Zod schema, do we need to dynamically import Zod as well?

I'm testing the package on a function and it works, but I think we forgot to emit some kind of warning/log/error when the parsing fails.

Is the Python implementation doing anything in this regard?

I think this is the python implementation for handling parsing failure. Should we do something similar?

I was trying to test it for Kinesis using https://github.com/dreamorosi/kinesis-batch and it was failing, trying to debug.

Message me, I got it working fine

Should we do something similar?

Yes, but in order to be able to do that we'll need to add a logger feature which we currently don't have.

Let's put a pin on this and I'll open a separate issue.

For new methods, I'd prefer creating signatures with objects rather than positional args since it makes it easier to read/understand at the call site.

For example, with the current signatures calling parseRecord looks like: await this.parseRecord(record, this.eventType, this.schema); which is not too bad because the args being passed are named correctly.

Calling createExtendedSchema instead looks much more opaque: await this.createExtendedSchema(eventType, schema, false) making it unclear what false stands for.

If the signature was:

private async createExtendedSchema(options: {
  eventType: keyof typeof EventType,
  schema: StandardSchemaV1,
  useTransformers: boolean
})

calling it would look like: await this.createExtendedSchema({ eventType, schema, useTransformers : false })` which is much clearer.

Also, unless the methods are public or protected, let's use #methodName instead of private methodName to make them truly private at runtime.

Using safeParse: true in this call will make it easier to add debug logs later since right now a failed parsing exits this scope.

Similarly, for the parse call above we could achieve the same without generating a stack trace, which can be more performant.

Same for the other @param added in this diff

Let's use punctuation correctly throughout the docstring.

We need to document schema so that customer know what it does and all its nuances.

Should we not do this check as the very first thing in this function? We're wasting work doing the parsing if all we're going to do is throw based on information we had before we began parsing.