When will this be out of Beta?

It's currently out of beta and is now the default runtime! Hope this helps.

Hey @Joroze, the page you linked is documentation on how to use edge api routes with Next.js and Vercel Edge which is a slightly different API than using Next.js with Netlify Edge.

Makes sense. Thanks!

Haha of course. I was initially confused by this as well. It's not clear.

Yes. You can use Next.js API routes with edge runtime though: we automatically include the compatibility layer, so you can use the Next.js syntax instead of the Netlify Edge Funciton syntax.

Hi ascorbic,

I am using nextjs 13 edge api route. Is the process.env still valid if converted to netilfy edge runtime ? I tried to use Netlify.env but seems not provided for NextJS API route. Does that mean I have to convert the api route to netilfy edge functions first ?

And using netlify-cli, is there a way I can see what api route is converted to netilify edge functions what are converted to regular functions ? Thank you ,

Summary: All of our deployments are working as long as they don't use regex in middleware matchers. @ascorbic

I've created a minimal reproduction and can confirm it doesn't work when regex are used in middleware matchers. I'm currently looking into this.

Actually, it is working. I somehow had installed an older version of the plugin and didn't clue in. I'm currently on the version 4.27.3 of the plugin. Here's what my middleware looks like.

import { MiddlewareRequest } from '@netlify/next';
export async function middleware(req) {
	const { pathname } = req.nextUrl;
	const request = new MiddlewareRequest(req);
	const res = await request.next();
	res.headers.set('x-show-pathname', pathname);
	res.headers.set('x-is-show', true);
	return res;
}
export const config = {
	matcher: [{ source: '/shows/((?!99|88).*)' }]
};

As long as the show isn't 88 or 99, you should see the x-show and x-is-show headers.

• https://6351b60978bc3f170e1d03c2--nextjs-middleware-matchers.netlify.app/shows/99 (no custom headers)
• https://6351b60978bc3f170e1d03c2--nextjs-middleware-matchers.netlify.app/shows/88 (no custom headers)
• https://6351b60978bc3f170e1d03c2--nextjs-middleware-matchers.netlify.app/shows/12 (yay! custom headers)

Here's the repository, https://github.com/nickytonline/matchers-with-regex-middleware-nextjs

CleanShot 2022年10月20日 at 17 05 14

CleanShot 2022年10月20日 at 17 06 35

@nickytonline Thanks for the working example! Can I ask you to try moving the lookahead up to the front? Our usage (and the one from the nextjs docs) begins with the (?!) pattern and my assumption is it's too aggressive and causing issues. So that any route that isn't /show triggers the middleware? The only other major difference I see is you're using netlify's request object. So I can try using that instead of the nextjs one in the meantime.

Alrighty... this took so much time to debug. So here's some code to look at...

import { NextRequest, NextResponse } from 'next/server';
export function middleware(request: NextRequest) {
 const url = request.nextUrl.clone();
 console.log( url.pathname );
 if (
 // ignore home page and any of the special urls, just continue
 url.pathname === '/' || url.pathname.match(/^\/api|assets|static|_next|.netlify|favicon.ico.*/)
 )
 return NextResponse.next();
 // redirect to "home" for anything else...
 url.pathname = '/';
 return NextResponse.redirect(url);
}
// export const config = {
// matcher: [
// // example from nextjs docs...
// // '/((?!api|static|favicon.ico).*)', // <- works locally but not in netlify.
// ],
// };

After playing around in regex101 for a while, I'm convinced whatever flavor of regex matcher uses is something else. It doesn't behave like I'd expect. So... I removed the matcher config and wrote the regex in the function... This works as I expect it to on local and in netlify.

In netlify, I noticed when I deployed the matcher with the example regex that /api/auth/session was triggering the middleware, even though, based on the commenting, urls starting with /api should be skipped. This is a special url from next-auth though... perhaps there is a conflicting or superseding rule for next-auth integration?

@nickytonline @ascorbic Thoughts welcome.