_middleware.ts doesn't work on translated routes

[michalpulpan]

Hello,

I really enjoy this library but I'm facing very weird behavior when using NextJS 12 _middleware.ts function.

Using _middleware.ts simple as:

import type { NextFetchEvent, NextRequest } from 'next/server'

const middleware = (req: NextRequest, ev: NextFetchEvent) => {
  return new Response('Hello, world!')
}

export default middleware;

works when:

- /pages
----/my-page <-- no _routes.json
--------index.tsx
--------_middleware.ts

And shows "Hello, world!"

But when I add _routes.json, middleware stops working.

- /pages
----/my-page
--------index.tsx
--------_routes.json <-- makes middleware not executing
--------_middleware.ts

It's quite important for me. Thanks!

[NikolaCava]

I have a similar problem, _middleware.tsx only works when I visit the "original" version of the route, but not when I use the translated route.

[cvolant]

@michalpulpan, @NikolaCava, could you try with the last version of Next (12.2.3)? Next team reworked the middleware (see this issue).

[NikolaCava]

@michalpulpan, @NikolaCava, could you try with the last version of Next (12.2.3)? Next team reworked the middleware (see this issue).

I did, still one problem... now getServerSideProps wont run when I change the language

[cvolant]

Hmm... It sounds more like a Next issue than a next-translate-routes issue... What do you think, @NikolaCava ?

[JamesHemery]

I think i've related issue. When I add a next 12.2 middleware (stable syntax), when a click on a Link the getStaticProps methods no longer work properly and _app pageProps is empty. All works perfectly when I reload the page.

[cvolant]

I reproduced the bug, and published the repro in this branch. As soon as a middleware is set up, getStaticProps fail for non default locales.

I looked into it but I did not find where it comes from yet.

[cvolant]

Some news: I investigated this bug further. It appears to be a Next issue.
I reported the issue in the next repo here.

The problem occurs when a matcher is declared in the middleware config. So, as long as the issue is not solved, we have 2 annoying options:

• either stick with next@12.1 and the previous middleware synthax,
• or remove the matcher from middleware config, and handle the selection from within the middleware.

[mlake]

I've been upgrading from 12.1.x to 12.3.4 and I'm running into the issue with translated paths (using _routes.json or routesTree). I've got articles.tsx and /en/blog but when I go to the page, I see the network is requesting _next/data/xxxxxxxx/en/blog.json which returns empty json response for the pageProps {} and messes up my page.
Prior to that, it looks like the browser is also requesting _next/data/xxxxxxxx/en/articles.json which does indeed have the right data.

I'm already upgrade-weary...but I'm noticing they introduced a new option in next 13.1 skipMiddlewareUrlNormalize

Seemingly we can capture /_next/data requests in middleware??

https://nextjs.org/docs/advanced-features/middleware

Is this helpful to you? I'm fumbling my way through it all..
(PS...i'm not seeing these issues on a local development run, but only after deploying to vercel...smoking head emoji)

[cvolant]

@mlake Sooo you have a /pages/articles.tsx page that you translate in 'en' to "blog"?

With a routes.json like this?

{
  "articles": {
    "en": "blog",
    ...
  },
  ...
}

[mlake]

that's right. It's called "blog" now ✊ (don't worry, there are legitimate translations!)
Actually my setup was like the following:

I forgot to note however, that I had followed nextjs' guide for setting up language detection by using an extra "default" locale in my configuration (you're supposed to turn off detection in the config, then use a middleware to do it server-side)

Today I've been experimenting with next 13.1 and trying to workaround using skipMiddlewareUrlNormalize to rewrite those .json requests to something that returns a response.

Probably this is doing something stupid, but I thought I'd share with you anyway:

import {setNtrData} from "next-translate-routes/react/ntrData";
import {urlToFileUrl, fileUrlToUrl} from "next-translate-routes";

const routesTree = require("./routesTree.json")

const MATCHER = /^(?<prefix>\/_next\/data\/.*?\/)(?<locale>.*?)(?<path>\/.*)\.json/

export const middleware = (req: NextRequest) => {

    // seems that _next/data requests don't come here unless you use next 13.1

    if (MATCHER.test(req.nextUrl.pathname)) {
        const result = MATCHER.exec(req.nextUrl.pathname)

        if (result?.groups?.prefix && result?.groups?.locale && result?.groups?.path){

            //console.log("prefix: " + result?.groups?.prefix)
            //console.log("locale: " + result?.groups?.locale)
            //console.log("path: " + result?.groups?.path)
            const ntrData = {
                defaultLocale: "default",
                locales: ["default", "en", "fr"],
                routesTree,
                debug: true
            }
            setNtrData(ntrData)
            const url = req.nextUrl.clone()

            url.pathname = result.groups.path
            const fileUrl = urlToFileUrl(url, result.groups.locale)

            if (!fileUrl) throw Error("fileUrl not found!")

            //console.log("fileUrl.pathname: " + fileUrl.pathname)
            url.pathname = fileUrl.pathname

            // console.log(url)

            const defaultUrlTranslated = fileUrlToUrl(
                fileUrl.pathname + url.search
            , "default")

            //console.log("defaultUrlTranslated: " + defaultUrlTranslated)

            const rewriteUrlPath = `${result.groups.prefix}${result.groups.locale}${defaultUrlTranslated}.json`

            //console.log("rewriteUrlPath: " + rewriteUrlPath)

            url.pathname = rewriteUrlPath

            return NextResponse.rewrite(new URL(url, req.url))
        }
    }
    // ....there's more

}

does actually return correct .json responses...but since it's 13.1 there's some other errors "Failed to lookup route" or 404s for some xxxx.json.js files that haven't figured out yet.

Sensing I'll need to do a U-turn from next 13...unless there are more options I haven't tried:

Thanks for any help!

[mlake]

Here's what I'm discovering with the following setup:
node: 18
next: 12.2.3
react: 17.0.2
next-translate-routes: 1.9.1

Using _routes.json in various spots
With some custom rewrites in next.config.js

If I use the following super-simple do-nothing middleware (no matchers or anything), there's no problem running locally (either dev or next build + next start)...BUT if I deploy this same middleware to Vercel, the pageProps are empty and I get client-side exception on my translated routes. frown emoji. sigh emoji.
without any middleware, the translated routes are fine.

// middleware.ts

import {NextRequest, NextResponse} from "next/server"

export function middleware(request: NextRequest) {
    return
}

[vbrzezina]

Here's what I'm discovering with the following setup: node: 18 next: 12.2.3 react: 17.0.2 next-translate-routes: 1.9.1

Using _routes.json in various spots With some custom rewrites in next.config.js

If I use the following super-simple do-nothing middleware (no matchers or anything), there's no problem running locally (either dev or next build + next start)...BUT if I deploy this same middleware to Vercel, the pageProps are empty and I get client-side exception on my translated routes. frown emoji. sigh emoji. without any middleware, the translated routes are fine.

// middleware.ts

import {NextRequest, NextResponse} from "next/server"

export function middleware(request: NextRequest) {
    return
}

Got the same experience, when using any middleware the translations stop loading when navigationg through links (works after refresh)

[cvolant]

Yes, next-translate-routes does not support next@13 yet.

And if you really need a middleware, as concluded here, you need either to downgrade next to 12.1 or remove the matcher. But according to @mlake , if you use Vercel, removing the matcher won't be enough... 😕

I invite all of you to upvote this issue on nextjs repo to help get this through.