Types not quite what i'd expect

[mobob]

Hey! Cool project, i'm a fan of onetable and have been mixing more zod in, so thought i'd give this a go.

I have some zod schema defined in a shared package in my monorepo, so i pull this in, then i added this chunk into my mega one table schema:

    Feedback: zodOneModelSchema(
      FeedbackRequestSchema.extend({
        pk: z.literal('FB#${feedbackId}'),
        sk: z.literal('TYPE#${_type}#VID#${_vendorListingId}'),
      }),
    ) as OneModel,

The casting to OneModel seemed necessary, it really broke the bounds of the overall structure without it.

And then further down i have a type for this entity:

export type FeedbackEntity = Entity<typeof FstaSchema.models.Feedback>;
export function modelFeedback(): Model<FeedbackEntity> {
  return ddbGlobalTable().getModel<FeedbackEntity>('Feedback');
}

However, when i try to use this (hover in vscode), it shows the type of these Entity objects is pretty unknown:

(alias) type FeedbackEntity = {
    [x: string]: undefined;
}
import FeedbackEntity

Whereas hovering over a different type that is not defined with zod and more explitily, you see all the bits, ie:

type BookingEntity = {
    bookingStatus: BookingStatus;
    created?: Date | undefined;
    updated?: Date | undefined;
    pk?: string | undefined;
    sk?: string | undefined;
    state?: string | undefined;
    bookingSummary?: string | undefined;
}

Is there any way to make this less opaque?

If you have any pointers let me know!

[jharlow]

Hi @mobob, thanks for trying it out and providing feedback. The package should be designed to give you native typing with no need for casting, so this is something I'd like to understand why you aren't getting that benefit.

I have a few questions so I can do a better investigation:

1. Can I just confirm that you're using compatible zod and dynamodb-onetable versions? Aka, compatible with zod@^3.23.8 and dynamo-onetable@^2.7.5.

2. Can I see the definition of FeedbackRequestSchema? I wonder if this is caused by some kind of incompatibility. On that note, what happens at that code-snippet at runtime with a logger instance? I baked in a lot of logger.warn/Errors for when a zod type can't be coerced into a dynamodb-onetable schema.

it('runtime test', () => {
zodOneModelSchema(
 FeedbackRequestSchema.extend({
   pk: z.literal('FB#${feedbackId}'),
   sk: z.literal('TYPE#${_type}#VID#${_vendorListingId}'),
 }),
 { logger } // 👈 winston Logger here
)
})

3. If you have time, would you pull this repo and just hover/try the typing in some of the model examples set up in test/zodOneModelSchema.spec.ts? Those are typing correctly as you expect for me, if they aren't for you it would help me narrow down on testing with different language server protocols.

Thanks again for the feedback, I hope I can help out!

[jharlow]

@mobob I've pulled this repo into my own VSCode (normally I use nvim) and IntelliJ Webstorm and the typing seems to be working for me. Looking forward to seeing that FeedbackRequestSchema is so I can try and do a reproduction of the issue.