Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

supabase.auth.api.getUserByCookie() doesn't work in Next.JS server-side environment #3783

Closed
vklimontovich opened this issue Nov 4, 2021 · 43 comments
Labels
bug Something isn't working

Comments

@vklimontovich
Copy link

Bug report

Describe the bug

supabase.auth.api.getUserByCookie() doesn't work in Next.JS server-side environment (_middleware.ts)

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

  1. Create a supabase project
  2. Create a Next.JS project
  3. Create

Add following code to _middleware.ts

export async function middleware(req: NextRequest, ev: NextFetchEvent) {
    let supabase = createClient(...);
    let user = await supabase.auth.api.getUserByCookie(req);
    console.log('Auth ', user)
}
  1. See logs
Auth  {
  user: null,
  data: null,
  error: ReferenceError: XMLHttpRequest is not defined
      at eval (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:462:17)
      at new Promise (<anonymous>)
      at fetch (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:455:12)
      at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:44:63)
      at new Promise (<anonymous>)
      at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:43:16)
      at Generator.next (<anonymous>)
      at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:16:71)
      at new Promise (<anonymous>)
      at __awaiter (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:12:12)
}

Expected behavior

getUserByCookie() should either work (use fetch() internally instead of XMLHttpRequest), OR message should be more clear (check the presence of XMLHttpRequest in getUserByCookie() and throw Sorry, you shouldn't call this method in server side environment

System information

Next version is 12.0.1

Additional context

Add any other context about the problem here.

@vklimontovich vklimontovich added the bug Something isn't working label Nov 4, 2021
@vklimontovich
Copy link
Author

FYI, this workaroung does the job:

    let supabase = createClient(supabaseUrl, supabaseKey);
    let token = req.cookies['sb:token'];
    if (!token) {
        return 
    }
    let authRequestResult = await fetch(`${supabaseUrl}/auth/v1/user`, {
        headers: {
            'Authorization': `Bearer ${token}`,
            'APIKey': supabaseKey
        }
    });

@kiwicopple
Copy link
Member

Hmm, odd since we're using cross-fetch: https://github.com/supabase/gotrue-js/blob/c213d2f02895248fc8d601a599116531be16071d/src/lib/fetch.ts#L1

I think the middleware is hosted on Cloudflare workers, so the other workaround is here: https://github.com/supabase/supabase/tree/master/examples/with-cloudflare-workers

@vklimontovich
Copy link
Author

I haven't deployed the app yet, so I believe that Cloudflare has nothing do to with it. It's reproducible with local next dev. I'll try to make an isolated example and maybe suggest a patch

@vklimontovich
Copy link
Author

Here's an isolated example: https://github.com/vklimontovich/supabase-nextjs-middleware

@saltcod
Copy link
Contributor

saltcod commented Nov 15, 2021

Not sure if the same issue or if I'm doing something wrong but:

I'm trying to use supabase.auth.api.getUserByCookie() in getServerSideProps and the user is always null.

export async function getServerSideProps({ req }) {
	const { user } = await supabase.auth.api.getUserByCookie(req);

	console.log({ user }); // always null

	if (!user) {
		return {
			props: {},
		};
	}

	return { props: { user } };
}

BUT! if I check client-side, I do have a user:

useEffect(() => { 
	checkUser();
}, []);


async function checkUser() {
	const user = await supabase.auth.user();
	console.log(user); // got a user here
}```

@vklimontovich
Copy link
Author

vklimontovich commented Nov 15, 2021

@saltcod have you set server cookie from client-side code? We published a post today, with a step-by-step guide on how to make next.js middleware work with Supabase auth: https://jitsu.com/blog/supabase-nextjs-middleware

@kiwicopple
Copy link
Member

Thanks for this @vklimontovich - I see also that you have the buggy code commented out in the example. We have rolled out the fix where you can provide a custom fetch implementation (since cross-fetch isn't working in Cloudflare Workers):

https://supabase.io/docs/reference/javascript/initializing#custom-fetch-implementation

You should be able to initialise the client like this:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient('https://xyzcompany.supabase.co', 'public-anon-key', { 
  fetch: fetch 
})

And after that supabase.auth.api.getUserByCookie(req) shouldn't be a problem

@emilioschepis
Copy link

@kiwicopple should that already be working with Next.js's fetch?

// src/supabaseClient.ts
import { createClient } from "@supabase/supabase-js";

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL as string;
const supabaseAnonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY as string;

const supabase = createClient(supabaseUrl, supabaseAnonKey, {
  fetch: fetch,
});

export default supabase;

I have this simple configuration, but I still get an error that refers to cross-fetch when checking the auth in a middleware function.

{
    token: null,
    user: null,
    data: null,
    error: ReferenceError: XMLHttpRequest is not defined
        at eval (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:462:17)
        at new Promise (<anonymous>)
        at fetch (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:455:12)
        at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:44:13)
        at new Promise (<anonymous>)
        at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:43:16)
        at Generator.next (<anonymous>)
        at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:16:71)
        at new Promise (<anonymous>)
        at __awaiter (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:12:12)
}

I have the latest version of supabase (1.28.0).

@NixBiks
Copy link

NixBiks commented Nov 20, 2021

Same here @emilioschepis

@kiwicopple
Copy link
Member

I've tested with the updated supabase-js on @vklimontovich 's demo above, and created a PR here:

https://github.com/jitsucom/supabase-nextjs-middleware/pull/1/files

I can confirm on this PR I'm not seeing this issue any more. Perhaps you can compare with your own implementation to see if there is anything missing?

@NixBiks
Copy link

NixBiks commented Nov 20, 2021

Odd. I have this in my _middleware.ts

import { supabase } from "@/services/supabase";
import { NextRequest, NextResponse } from "next/server";


export async function middleware(req: NextRequest) {
  const {user, token, error} = await supabase.auth.api.getUserByCookie(req)
  console.log(error)  
   ...

The error is ReferenceError: XMLHttpRequest is not defined

And this is how I export my supabase client

import { createClient } from "@supabase/supabase-js";

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL;
const supabaseAnonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY;

if (!supabaseUrl || !supabaseAnonKey)
  throw new Error(
    "Need to set NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY"
  );

export const supabase = createClient(supabaseUrl, supabaseAnonKey, {
  fetch: fetch
});

Running v1.28.0. Am I missing something obvious here?

@vklimontovich
Copy link
Author

Very weird, @kiwicopple's PR didn't work for me as well. I tried to replace custom fetch with:

  return createClient(process.env.NEXT_PUBLIC_SUPABASE_URL, process.env.NEXT_PUBLIC_SUPABASE_KEY, {
    // @ts-ignore
    fetch: (...args) => {
      console.log("Args", args)
    },
  })

And I'm still seeing same error (meaning custom fetch wasn't passed to gotrue-js):

Authorization error, redirecting to login page ReferenceError: XMLHttpRequest is not defined
    at eval (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js:462:17)
    at new Promise (<anonymous>)
    at fetch (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js:455:12)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js:44:13)
    at new Promise (<anonymous>)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js:43:16)
    at Generator.next (<anonymous>)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js:16:71)
    at new Promise (<anonymous>)
    at __awaiter (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js:12:12)

(I did rm -rf node_modules && rm -rf yarn.lock && yarn install to make sure all packages are uptodate)

@NixBiks
Copy link

NixBiks commented Nov 20, 2021

Could this be M1 related somehow?

@NixBiks
Copy link

NixBiks commented Nov 21, 2021

Could this be M1 related somehow?

No. Just tested on my ubuntu desktop and I'm getting the same error. Versions:

❯ yarn info | grep supabase-js -A 8
├─ @supabase/supabase-js@npm:1.28.0
│  ├─ Version: 1.28.0
│  │
│  └─ Dependencies
│     ├─ @supabase/gotrue-js@npm:^1.21.0 → npm:1.21.1
│     ├─ @supabase/postgrest-js@npm:^0.35.0 → npm:0.35.0
│     ├─ @supabase/realtime-js@npm:^1.2.1 → npm:1.2.1
│     └─ @supabase/storage-js@npm:^1.5.0 → npm:1.5.0

@thorwebdev
Copy link
Member

thorwebdev commented Nov 22, 2021

It sounds like simply importing cross-fetch causes this error to be thrown: lquixada/cross-fetch#69

If that's the case, the above mentioned workaround might be your best bet for now: #3783 (comment)

Or you can try the patch-package approach from https://github.com/supabase/supabase/tree/master/examples/with-cloudflare-workers

@kiwicopple
Copy link
Member

after more thorough testing I found the error was persisiting. sorry about the false posititve.

I added another commit to the PR, based on Thor's link to the cross-fetch package - in particular, this comment. I can confirm that this works in Next.js middleware, on a local environment.

I'll follow up on the linked package and see if that change is OK to merge

@gabrielsestrem
Copy link

Thanks @kiwicopple . I am also waiting for this to implement the _middleware.ts to our pages that requires SSR for Authentication.

@mauricedesaxe
Copy link

supabase.auth.api.getUserByCookie(req) doesn't work in getServerSideProps (only in production for me either).

I've tried so many things, including what the OP wrote in this article here.

Any updates on this?

@KushibikiMashu
Copy link

Error still occurs in middleware on Next.js dev server.

"next": "^12.0.4"
"@supabase/supabase-js": "^1.28.5"

ReferenceError: XMLHttpRequest is not defined
    at eval (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:462:17)
    at new Promise (<anonymous>)
    at fetch (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:455:12)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:44:13)
    at new Promise (<anonymous>)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:43:16)
    at Generator.next (<anonymous>)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:16:71)
    at new Promise (<anonymous>)
    at __awaiter (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:12:12)

@kiwicopple
Copy link
Member

ReferenceError: XMLHttpRequest is not defined

If this is the error then you probably want to provide a different Fetch provider: https://supabase.com/docs/reference/javascript/initializing#custom-fetch-implementation

@yudyananda
Copy link

yudyananda commented Jan 18, 2022

ReferenceError: XMLHttpRequest is not defined

If this is the error then you probably want to provide a different Fetch provider: https://supabase.com/docs/reference/javascript/initializing#custom-fetch-implementation

@kiwicopple it work like a charm in my middleware but somehow i cannot longer fetch the table in the client-side. any idea?

export const supabase = createClient(supabaseUrl, supabaseToken, {
   fetch,
});

const sessionUser = supabase.auth.user();
const { data: profile } = await supabase
    .from('profile')
    .select('*')
    .eq('id', sessionUser.id)
    .single();
   console.log('profile :', profile);  // always null

@kiwicopple
Copy link
Member

It seems that might be an unrelated issue @yudyananda - you're welcome to start a new issue (so this one doesnt get sidetracked). It could be any of: not authenticated, RLS, sessionUser.id is not returned, there could be an error returned const { data: profile, error }

@tchief
Copy link

tchief commented Jan 20, 2022

@yudyananda @kiwicopple I noticed this as well. As a workaround used 2 instances of SupabaseClient: one for client side (without custom fetch) and one for server side with this PR applied.

@Murkrage
Copy link

I was suffering from the same issue server side as has been mentioned a couple times here: getUserByCookie() returns null even though the client returns a user as expected. I'm using a magic link as my login method and what I noticed was that my session cookie wasn't set.

I found this post on dev.to that solves my problem. OP uses supabase.auth.onAuthStateChange() and supabase.auth.api.setAuthCookie() to manually set the supabase cookie client side. Once that's happened the server correctly fetches the user.

The following is added to the _app.tsx:

useEffect(() => {
    const { data: authListener } = supabase.auth.onAuthStateChange(
      (event, session) => {
        if (event === "SIGNED_IN") {
          updateSupabaseCookie(event, session);
        }
      }
    );

    return () => {
      authListener?.unsubscribe();
    };
  });

  async function updateSupabaseCookie(event: string, session: Session | null) {
    await fetch("/api/auth", {
      method: "POST",
      headers: new Headers({ "Content-Type": "application/json" }),
      credentials: "same-origin",
      body: JSON.stringify({ event, session }),
    });
  }

The following is added to /api/auth.ts:

const handler = (req: NextApiRequest, res: NextApiResponse) => {
    supabase.auth.api.setAuthCookie(req, res);
};

The supabase.auth.api.XXX methods aren't documented anywhere. As far as I can tell at least. It seems to do the trick, though. Not sure if this is the desired implementation, would love to get feedback on this.

@ingokpp
Copy link
Contributor

ingokpp commented Feb 13, 2022

I have another workaround. A one liner 😊

supabase.auth.setAuth(req.cookies['sb:token']);

This requires that the cookie is set on auth change like mentioned before :)

@Hallidayo
Copy link
Contributor

I was suffering from the same issue server side as has been mentioned a couple times here: getUserByCookie() returns null even though the client returns a user as expected. I'm using a magic link as my login method and what I noticed was that my session cookie wasn't set.

I found this post on dev.to that solves my problem. OP uses supabase.auth.onAuthStateChange() and supabase.auth.api.setAuthCookie() to manually set the supabase cookie client side. Once that's happened the server correctly fetches the user.

The following is added to the _app.tsx:

useEffect(() => {
    const { data: authListener } = supabase.auth.onAuthStateChange(
      (event, session) => {
        if (event === "SIGNED_IN") {
          updateSupabaseCookie(event, session);
        }
      }
    );

    return () => {
      authListener?.unsubscribe();
    };
  });

  async function updateSupabaseCookie(event: string, session: Session | null) {
    await fetch("/api/auth", {
      method: "POST",
      headers: new Headers({ "Content-Type": "application/json" }),
      credentials: "same-origin",
      body: JSON.stringify({ event, session }),
    });
  }

The following is added to /api/auth.ts:

const handler = (req: NextApiRequest, res: NextApiResponse) => {
    supabase.auth.api.setAuthCookie(req, res);
};

The supabase.auth.api.XXX methods aren't documented anywhere. As far as I can tell at least. It seems to do the trick, though. Not sure if this is the desired implementation, would love to get feedback on this.

I have the same sort of implementation as this but in a AuthContext and this for me works well with the cookie being set manually

@thorwebdev
Copy link
Member

I'd recommend using https://github.com/supabase-community/supabase-auth-helpers/blob/main/src/nextjs/README.md going forward.

@Murkrage
Copy link

Murkrage commented Mar 4, 2022

@thorwebdev Is there a way to refresh the user's token so they aren't logged out after the max expiry of 1 week using the auth-helper? That's the one thing I'm struggling with right now.

@thorwebdev
Copy link
Member

thorwebdev commented Mar 7, 2022

@Murkrage the auth helper library stores the account_token as well as the refresh_token in secure server cookies, and automatically refreshes the account_token when it is expired. This way the user should theoretically never get logged out as the refresh_token doesn't expire.

Are you saying you've had issues with that using the auth helpers, or this is a problem you're currently facing not using the auth helpers?

NOTE: by default the cookies will expire after 8h. If you want the user to stay logged in longer, you can set the lifetime in the cookieOptions like so: https://github.com/vercel/nextjs-subscription-payments/pull/104/files

@thorwebdev
Copy link
Member

Closing this out, as mentioned, please use https://github.com/supabase-community/supabase-auth-helpers/blob/main/src/nextjs/README.md going forward and open issues there if you encounter any. Thanks 💚

@IHIutch
Copy link
Contributor

IHIutch commented Jun 15, 2022

@IHIutch
Copy link
Contributor

IHIutch commented Jun 15, 2022

I'm a little confused by this suggestion because the documented example uses the @supabase/ui Auth which I've found tends to obfuscate what is actually happening when authenticating. I appreciate that this community package appears to solve some issues (Does it actually solve the _middleware issue? I'm not seeing that confirmed anywhere) but I still feel a bit in the dark on some other things.

My 2 cents:

  1. Am I required/expected to use @supabase/ui Auth when handling auth when using Supabase? That feels odd to me.
  2. Using a community package to circumvent an issue with Supabase and NextJS doesn't feel like a "Closed" worthy resolution, imho
    • Further, having to install 2 additional packages feels like a weird solution. Temporary, sure, but as a permanent solution?
  3. In my app specifically, I use a /api/auth/register route to create a user in my DB and sign them in. It's unclear to me how I'd do that using the community package

I don't mean to offend, I'm an intermediate developer at best, I'm just trying to understand and leverage the incredible framework that is Supabase. But as such, I'm really struggling to understand the solution here. My app works fine, with everything except getUserByCookie when using _middleware, so this feels like an additional piece of complexity to understand and keep up with as things change.

If anyone can shed some light, I'm eager to understand better, thanks.

@thorwebdev
Copy link
Member

Thanks for the feedback @IHIutch, I understand your frustration, a bunch of things are in flux atm which creates this less than ideal experience 😞

  1. Am I required/expected to use @supabase/ui Auth when handling auth when using Supabase? That feels odd to me.

Not at all a requirement. The Auth UI Element is solely meant to make things faster/easier by giving you a prebuilt UI, but not at all a requirement. You can always built your custom UI if you prefer.

  1. Using a community package to circumvent an issue with Supabase and NextJS doesn't feel like a "Closed" worthy resolution, imho

It's technically not an issue, or at least not a bug, since you very well can set the cookies yourself if you want. It's just not the easiest thing to do. So having some convenience libraries to help you with this is our philosophy here.

Further, having to install 2 additional packages feels like a weird solution. Temporary, sure, but as a permanent solution?

Again, all of these are optional and are meant as a convenience. the @supabase/auth-helpers are non-ui helpers and the @supabase/auth-ui (https://github.com/supabase-community/auth-ui) is where the Auth UI Elements will be moved to in the future.

Does it actually solve the _middleware issue

It does, have a look at the example here: https://github.com/supabase-community/auth-helpers/blob/main/examples/nextjs/pages/middleware-protected/_middleware.ts

Sorry, we're working on improving this experience, just a lot of moving parts right now. We really appreciate your feedback and will use it to improve things!

@IHIutch
Copy link
Contributor

IHIutch commented Jun 17, 2022

Thanks @thorwebdev, I appreciate the response. Genuinely, Supabase has such a great community and I appreciate the conversation.

@cagils
Copy link

cagils commented Jul 7, 2022

What is the current suggestion if I just want to check for authenticated user in the getServerSideProps (not using next js api for auth) and if I do not prefer to use auth-helpers?

@kiwicopple
Copy link
Member

kiwicopple commented Jul 9, 2022

If you prefer not to use the helpers, you would probably want to follow the same process in the helpers code. eg: set the Auth token inside a cookie, and then extract the value of the cookie inside getServerSideProps - the idea of the helpers isn't to do anything unique, it's simply to provide a library which will follow the same steps that you'd do yourself

@Jordaneisenburger
Copy link

I was suffering from the same issue server side as has been mentioned a couple times here: getUserByCookie() returns null even though the client returns a user as expected. I'm using a magic link as my login method and what I noticed was that my session cookie wasn't set.

I found this post on dev.to that solves my problem. OP uses supabase.auth.onAuthStateChange() and supabase.auth.api.setAuthCookie() to manually set the supabase cookie client side. Once that's happened the server correctly fetches the user.

The following is added to the _app.tsx:

useEffect(() => {
    const { data: authListener } = supabase.auth.onAuthStateChange(
      (event, session) => {
        if (event === "SIGNED_IN") {
          updateSupabaseCookie(event, session);
        }
      }
    );

    return () => {
      authListener?.unsubscribe();
    };
  });

  async function updateSupabaseCookie(event: string, session: Session | null) {
    await fetch("/api/auth", {
      method: "POST",
      headers: new Headers({ "Content-Type": "application/json" }),
      credentials: "same-origin",
      body: JSON.stringify({ event, session }),
    });
  }

The following is added to /api/auth.ts:

const handler = (req: NextApiRequest, res: NextApiResponse) => {
    supabase.auth.api.setAuthCookie(req, res);
};

The supabase.auth.api.XXX methods aren't documented anywhere. As far as I can tell at least. It seems to do the trick, though. Not sure if this is the desired implementation, would love to get feedback on this.

Just to confirm, this manual work is still needed even when using https://github.com/supabase-community/auth-helpers/tree/main/packages/nextjs#basic-setup correct ?

@thorwebdev
Copy link
Member

Nope, the auth helpers take care of this for you vis the UserProvider component that you wrap your app in.

@Jordaneisenburger
Copy link

Jordaneisenburger commented Jul 21, 2022

Mhh thats interesting because without it the magic link login doesn't work the first time and you need to manually refresh the page or it simply doesnt login at all in production.

It's possible that I might be doing something wrong ofcourse. But I'm pretty sure simply using the UserProvider doesnt cover all cases perse

@thorwebdev
Copy link
Member

The magic link redirect will need to go to a page that has the UserProvider first in order to set the cookie. Only after that the SSR stuff will work.

@tomedalya
Copy link

We published a post today, with a step-by-step guide on how to make next.js middleware work with Supabase auth: https://jitsu.com/blog/supabase-nextjs-middleware

@vklimontovich seems like this does not work anymore with the newer version of supabase (1.35.6)
the token is not under sb:token and even after changing to sb-access-token there is an error
Error [TypeError]: Cannot delete property 'Symbol(set-cookie)' of #<HeadersList2>

@wiesson
Copy link

wiesson commented Oct 25, 2022

Nextjs 13 has been released and they provide a new way of fetching data.

// app/page.js
import { use } from 'react';

async function getData() {
  const res = await fetch('...');
  const name: string = await res.json();
  return name;
}

export default function Page() {
  // This value is fully typed
  // The return value is *not* serialized
  // so you can return Date, Map, Set, etc.
  const name = use(getData());

  return '...';
}

(taken from here https://nextjs.org/blog/next-13#data-fetching)

I have a similar error:

wait  - compiling /(app)/app/requests/page (client and server)...
warn  - ./node_modules/.pnpm/node-fetch@2.6.7/node_modules/node-fetch/lib/index.js
Module not found: Can't resolve 'encoding' in '/Users/wiese/Dev/tm/next-13/node_modules/.pnpm/node-fetch@2.6.7/node_modules/node-fetch/lib'

pnpm why node-fetch shows that cross-fetch uses fetch2.6.7

If I try to use another fetch implementation, I get ESM import errors. With node18, it works btw. (still errors, but the page renders and supabase client works)

@thorwebdev
Copy link
Member

Next.js 13 discussion moved -> supabase/auth-helpers#341

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests