Middleware config matcher settings

[antofopera]

Summary

If I use a configuration like this in middleware.ts:

const pathAuth: readonly string[] = ["/dashboard/(.*)", "/private/(.*)"];
const pathLocale: readonly string[] = ["/article/(.*)", "/article"];

export const config = {
  matcher: [...pathAuth, ...pathLocale],
};

A warning occurs:

⚠ ./middleware.ts
Unable to parse config export in source file
The exported configuration object in a source file need to have a very specific format from which some properties can be statically parsed at compiled-time.

But if I change it to:

const pathAuth: string[] = ["/dashboard/(.*)", "/private/(.*)"];
const pathLocale: string[] = ["/article/(.*)", "/article"];

// export const config = {
//   matcher: [...pathAuth, ...pathLocale],
// };

export const config = {
  matcher: ["/dashboard/(.*)", "/private/(.*)", "/article/(.*)", "/article"],
};

The problem is gone.

But I want to group related paths, how should I accomplish this?

I searched the issues for an answer, but not much was found.

Additional information

No response

Example

No response

[hyjoong]

Looking at the Next.js Middleware documentation (https://nextjs.org/docs/app/building-your-application/routing/middleware#matching-paths), it states that "matcher values need to be constants so they can be statically analyzed at build-time. Dynamic values such as variables will be ignored."

The spread operator (...) is considered a dynamic expression, so while your approach using [...pathAuth, ...pathLocale] would make the code cleaner and more maintainable, it unfortunately can't be used for static analysis at build time.

[icyJoseph]

As the other comment says, things such as:

export const config =  {
  matcher: someValue ? ["/dashboard/(.*)", "/private/(.*)", "/article/(.*)", "/article"] : [],
};

Or, [...foo], or [/* some values */].map(), or filtering, etc, are all disallowed. The middleware file is first parsed into AST, by SWC, and then some validations are made, one of those is, validating how export config exists, and they do narrow it down to a bunch of static AST variations.

You can see,

next.js/crates/next-core/src/util.rs

Line 567 in be99a2f

parse_route_matcher_from_js_value(module.ident(), value)

, for parse_config_from_js_value, or parse_route_matcher_from_js_value, - it was a lot more accessible for non rustaceans, when this was done in JavaScript 😅

[shape1541]

Thanks for the insights about the middleware implementation. When diving into the Next.js repository, there are numerous files containing 'middleware' in their names, which makes it challenging to locate specific implementations. I'm curious about your approach to finding these specific files. Beyond middleware, I'd love to understand your general methodology for tracing implementations of Next.js features (like next/navigation or next/image) in the codebase. Could you share your process for effectively navigating through the Next.js repository to find specific implementation details

[icyJoseph]

Well, for build for example, https://github.com/vercel/next.js/blob/canary/packages/next/src/build/index.ts, I'd start there, and I have been exploring the code base for a while now, to know to look for the server/render.tsx, or server/next.ts folder, etc... but I also try to do debugging and my own local builds to output more information about where an issue might be happening. This is why a reproduction repository, or at least, some snippets I could start from are very much a time saver.

Often people would also say, after this x.y.z version, this code stopped working, or some variation of this, and then I can try to find the commits in between a good release and a bad release, and then more or less estimate which commit broke the behavior, and there one can learn which code is responsible for what.

[shape1541]

Thank you so much for sharing such detailed insights into navigating the Next.js codebase! Your approach of using version differences and local debugging to trace implementations is really helpful. Much appreciated!