Middleware enhancements after new Next.js middleware architecture

[amannn]

Is your feature request related to a problem? Please describe.

It seems like there's work happening on the Next.js side on a middleware revamp: vercel/next.js#46722 (comment)

I'm using this thread to collect aspects about the current next-intl middleware that we could potentially address in case a revamp is relevant after the Next.js change.

Describe the solution you'd like

My personal wishlist for Next.js:

1. Passing a locale to the rendering phase (see Reading params deeply in Server Components (e.g. for i18n / multi-tenancy) vercel/next.js#58862). Ideally this would be possible without a middleware in the first place though.
2. A dynamically created matcher

Mentioned both here.

Separately from this, there are some use cases we could support better that do not rely on Next.js:

1. Get the locale within middleware #1356
2. Locale detection could be more flexible #1369
3. Maybe opting out of root-redirect? Possibly already by adapting the matcher, but would there be an advantage to make this more explicit?
4. Should the middleware automatically decide if a request should be handled or not (see example from docs), allowing us to remove the default matcher? (might need an option to opt-out) We'd only be able to do it for the localePrefix: 'always' case though (and only if the user doesn't want to automatically redirect /users → /en/users). Is this helpful?

We can make these changes in any case, but in case a refactoring is necessary after the Next.js change, maybe it'd be worth waiting a bit.

[amannn]

Seems like there's some movement here: vercel/next.js#70961.

As far as I understand the feature, it's mostly targeted at validation. The best I can think of is a validation that the [locale] param contains a valid value and alternatively call notFound(). This would be a slight improvement, but if the mere presence of an interceptor opts the page into dynamic rendering, this already has a downside in comparison to running the validation in [locale]/layout.tsx.

From a first glance, the new interceptors feature currently doesn't look like it could help with the pain points that were mentioned above. I'll keep an eye on it though.

[Kuchasz]

Next-intl's middleware must be the first one that produces the response to work properly. It won't use response produced by the others even if does not do any redirects. It makes way harder to make it work with any middlewares composer. I've built a clunky solution which has one huge limitation - next-intl middleware must be always first in chain. Other middlewares just append some stuff to the generated response.

Accepting optional NextResponse as argument in next-intl's middleware could solve. Not sure if anyone else would like to use it xD

Even the docs see here somewhere in between states that this middleware is the only one that should produce the happy path response. Do you have any thoughts on that? Maybe i may solve that differently or you can propose some more extensible solutions in next-intl middleware.

[armandabric]

I getting in the same gotcha as @Kuchasz. The current next-intl isn't chain-able easily. If possible it could be a good idea to improve this as next.js push us to use more and more the middleware.