`@supabase/ssr` should include `@types/cookie` as a (non-dev) dependency

[dawaltconley]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

The server client example for NextJS setups throws errors with stricter TS/ESLint configs (specifically with the @typescript-eslint/no-unsafe-argument rule):

// from https://supabase.com/docs/guides/auth/server-side/nextjs
import { createServerClient, type CookieOptions } from '@supabase/ssr'
import { cookies } from 'next/headers'

export function createClient() {
  const cookieStore = cookies()

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        get(name: string) {
          return cookieStore.get(name)?.value
        },
        set(name: string, value: string, options: CookieOptions) {
          try {
            // ERROR: Unsafe argument of type `any` assigned to a parameter of type `[key: string, value: string, cookie?: Partial<ResponseCookie> | undefined] | [options: ResponseCookie]`
            cookieStore.set({ name, value, ...options })
          } catch (error) {
            // The `set` method was called from a Server Component.
            // This can be ignored if you have middleware refreshing
            // user sessions.
          }
        },
        /* ... */
      },
    }
  )
}

It's not immediately obvious when trying to debug but { name, value, ...options } evaluates to any. This is because CookieOptions is an alias for a type provided by the @types/cookie package, but this is a devDependency, so it's not being installed with @supabase/ssr:

// from dist/index.d.ts
import { CookieSerializeOptions } from 'cookie';

type CookieOptions = Partial<CookieSerializeOptions>;

As is, CookieOptions is basically an obscured any type, which only makes the type issues harder to debug.

To Reproduce

Attempt to use the server client example in any project with @typescript-eslint/no-unsafe-argument set to error.

Expected behavior

This can be fixed by adding @types/cookie to a project manually, but it would be better to include the package with @supabase/ssr.

[encima]

Transferred to auth for the right eyes. PRs welcome as well!

[rbutera]

I've created a PR over at @supabase/auth-helpers:

supabase/auth-helpers#781

Thank you @dawaltconley for figuring this out as it was a bit of a head scratcher for me!

[ryangriffinau]

Had the same issue and could not work it out - thanks @dawaltconley !

[Simplereally]

Ran into this issue today and was banging my head against the wall for a while.

For those who are unsure of the solution:

1. Install cookie type as dev dependency as OP mentioned via bun add @types/cookie -d or npm i -d @types/cookie
2. Update server.ts to include:

import { type CookieSerializeOptions } from "cookie";
type CookieOptions = Partial<CookieSerializeOptions>;

3. Use it in the set function:

cookiesToSet.forEach(({ name, value, options }) =>
    cookieStore.set(name, value, options as CookieOptions),
);

[J0]

Hey everyone,

Thanks for the feedback. I can relate to the issue of having to manually install the types package and potentially doing some head scratching if one does not install it. However, my understanding is that types generally live as dev dependencies by convention and listing it as a prod dependency instead would force users to opt in even if they do not need the types

Leaving it as a dev dependency provides more optionality and I'm currently in favour of that. I think we can look into better documenting this on the SSR guide

I'll also check in with the team to see what they think. In the meantime let us know if there are any questions/concerns or more arguments for/against inclusion.

Thanks

[dawaltconley]

For what it's worth, I do not think the convention on this is very clear or well-established, but I've seen more recommendations for library authors to install any exposed type dependencies as non-dev than dev (see here and here). The most contentious case is @types/node, since this introduces globals and is often installed manually.

In my view, every Typescript project already ships types to all users via declaration files, whether they use them or not. Unless you go pure JavaScript, it's really a choice between shipping complete vs incomplete types to all users. I know it's "one more dependency," but type packages are very small and usually (as in this case) 0 deps.

But I can't claim that's a universal view. Including @types/cookie in the installation part of the docs would probably resolve the confusion for most users (though it should probably be under optionalDependencies in that case).

[J0]

Hey,

We've decided to include it. Thanks!