Typescript errors when using Stripe with 1.18.0

[dT-Nick]

What version of Remix are you using?

1.18.0

Are all your remix dependencies & dev-dependencies using the same version?

• Yes

Steps to Reproduce

Here is a typescript playground reproduction

• Create a variable with the type Stripe.InvoiceLineItem in a loader.
• Return the variable from the loader.
• Access the loader data or variable from useLoaderData.

Expected Behavior

Everything to work with no issues, like when using the type inside a loader before it's gone through remix's loader data serializing/prettifying process.

Actual Behavior

It produces the following typescript errors:

Type of property 'customer' circularly references itself in mapped type 'SerializeObject<UndefinedToOptional<Card>>'.ts(2615)
Type of property 'customer' circularly references itself in mapped type '{ [K in keyof SerializeObject<UndefinedToOptional<BankAccount>>]: SerializeObject<UndefinedToOptional<BankAccount>>[K]; }'.ts(2615)
Type of property 'customer' circularly references itself in mapped type '{ [K in keyof SerializeObject<UndefinedToOptional<Card>>]: SerializeObject<UndefinedToOptional<Card>>[K]; }'.ts(2615)
Type of property 'file' circularly references itself in mapped type 'SerializeObject<UndefinedToOptional<FileLink>>'.ts(2615)
Type of property 'links' circularly references itself in mapped type 'SerializeObject<UndefinedToOptional<File>>'.ts(2615)

Presumably due to the potentially cyclic nature of the stripe API if you expand these properties. I receive those errors when I try and directly access the object with the lineItems inside - not on the useLoaderData function call, like in the typescript playground reproduction.

EDIT: Similar to #6693 and #6558 (#6558 was resolved, so hoping this can also be resolved).

[piotrkulpinski]

I'm seeing the same issues in v1.18.0.

[piotrkulpinski]

Temporary workaround for me:

const loaderData = useLoaderData<typeof loader>()

const subscription = loaderData?.subscription as unknown as Stripe.Subscription
const invoices = loaderData?.invoices as unknown as Stripe.Invoice[] | null

You just gotta find out what the Stripe type is for the data you're using.

[dT-Nick]

Temporary workaround for me:

const loaderData = useLoaderData<typeof loader>()

const subscription = loaderData?.subscription as unknown as Stripe.Subscription
const invoices = loaderData?.invoices as unknown as Stripe.Invoice[] | null

You just gotta find out what the Stripe type is for the data you're using.

Unfortunately this doesn't work for my use case, as I'm using the Stripe.InvoiceItem type directly. That seems to be where the issue is coming from, like in the typescript playground reproduction I shared. Can't find a way to make a temporary workaround like above within that reproduction.

[pcattori]

Looking into this reveals that TS is actually inferring the correct types. So not sure if this is a false positive.

As a workaround, you can use @ts-expect-error and still have type inference flowing through your app:

  // @ts-expect-error
  const loaderData = useLoaderData<typeof loader>()

Keeping an eye on this to see if its a TS issue or a Remix issue.

[dT-Nick]

I've managed to find a workaround it by doing something similar to @piotrkulpinski - just not a very elegant solution, but enough for typechecks to pass as a temporary solution.

The only thing I know is that I'm not having any of these issues until it's gone through the Remix loader. I've obviously no idea whether it'd be a TS or Remix issue, but it seems odd that if it were a TS issue there aren't any issues from the stripe API directly when used in the loader or regular typescript, only when consuming it from useLoaderData - that and the fact that it wasn't an issue in 1.17.X (although #6558 was a similar issue with Prisma types in that version and that's solved now).

[pcattori]

Here's the smallest reproduction I've made so far.

For example, using this type:

type X = {
  x?: X
}

...my mental model so far:

Left	Right	Commentary
X	Serialize<X>	No primitives to compare, let's unwrap Serialize<X> one level
X	{ x?: Serialize<X> }	So far, right-side could be X. x? key looks correct. Let's check the value
X	{ x?: { x?: Serialize<X> }}	Ok, next level looks good. x?.x? key looks correct. Let's check the value
X	{ x?: { x?: { x?: Serialize<X> }}}	...
...	...	...

^ so the cycle get's detected by TS, but TS hasn't reduced the problem at all. It's still trying to answer "Is X assignable to Serialize<X>?" at every level.

[github-actions]

🤖 Hello there,

We just published version 1.18.1-pre.2 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version 1.18.1 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!