Rewrites are only configurable at build time

[ffleandro]

Run next info (available from version 12.0.8 and up)

Operating System:
Platform: darwin
Arch: x64
Version: Darwin Kernel Version 20.4.0: Fri Mar 5 01:14:14 PST 2021; root:xnu-7195.101.1~3/RELEASE_X86_64
Binaries:
Node: 16.13.2
npm: 8.1.2
Yarn: 1.22.17
pnpm: 6.29.1
Relevant packages:
next: 12.0.10
react: 17.0.2
react-dom: 17.0.2

What version of Next.js are you using?

12.0.10

What version of Node.js are you using?

16.13.2

What browser are you using?

Chrome

What operating system are you using?

macOS

How are you deploying your application?

next start

Describe the Bug

rewrites() in next.config.js is only called at build time.
IMHO it should be called at run time.

Use Case: If I don't know beforehand the url to where I want to rewrite I can't define it at runtime from an Environment variable.

Expected Behavior

rewrites() should be called at runtime so that we can have a dynamic rewrite url using an env variable.

To Reproduce

put a log in rewrites() in next.config.js and verify that it is only called at build time and not at runtime.

[balazsorban44]

This is correct and expected. If you need a more dynamic way, you can have a look at Middleware: https://nextjs.org/docs/middleware

[stigkj]

As far as I know, this only happens for static pages, i.e. if you change to use getServerSideProps instead of getStaticProps the method should be called each time. But I guess middleware is a better solution :-)

[ffleandro]

Thanks, solved this with middleware and it fitted perfectly to what I was looking for.

[qgerome]

Hi @ffleandro ! Do you mind sharing your solution ? I have the same problem and can't find a clean solution :/

[ffleandro]

@qgerome Sure, you can also check more information in the documentation here: https://nextjs.org/docs/advanced-features/middleware

import { NextFetchEvent, NextRequest, NextResponse } from 'next/server';

export const myMiddleware = (req: NextRequest): NextResponse | undefined => {
  const { pathname } = req.nextUrl;

  if(pathname === myCondition) {
    const destination = new URL('http://myurltorewrite.com');
    const url = req.nextUrl.clone();
    url.host = destination.host;
    url.port = destination.port;
    url.pathname = pathname;
    return NextResponse.rewrite(url);
  }

  // else do nothing...
};

export function middleware(req: NextRequest, ev: NextFetchEvent) {
   const response = myMiddleware(req);

    if (response) return response;
    // else, execute next middleware
}

This has been redacted since I have other business logic here so it may contain errors.
For more details check my full code here: https://github.com/entando/entando-webui/blob/master/starters/barebone-nextjs-engine/pages/_middleware.ts

[yaroslav-koval]

it's the most useful comment for today, ty

[heymath]

The problem is that Middelwares do not provide route matching, with path params detection, path params replacement, multi lang/domains support, etc.

And we don't want to code ourself a path/route matching strategy, ranking the routes to know if the path is more likely to match this route or another one... then extract params in the current path to create the path in an other languages where words will be different, maybe params order too, etc.

---

🎉 Next config rewrites is very nice to handle such advanced things :

{
    rewrites: async () => {
        return {
            beforeFiles: [
                {
                    source: '/:destinationSlug/viajes/',
                    destination: '/:destinationSlug/travel/',
                    has: [{ type: 'host', value: 'www.local.example.es' }],
                },
                {
                    source: '/voyage/:destinationSlug/',
                    destination: '/:destinationSlug/travel/',
                    has: [{ type: 'host', value: 'www.local.example.fr' }],
                },
                // a lot more...
            ],
        };
    }
}

➡️ Note that we can generate this config from our route.json config file and not hard code each rewrite for each route.

❌ But because we know the host value via an env variable at runtime, we can not use Next config rewrites ...
(we do this to avoid to build a Docker image and assets for each environment because this is bad)

⬇️ This is not possible and very sad 😞 (only possible if the env var is set at buildtime, but it makes no sense for this kind of var because we want the same build for any env as said before)

// NEXT_PUBLIC_HOST_ENV may equal 'local.' or 'preprod.' or '', at runtime only
{
    rewrites: async () => {
        return {
            beforeFiles: [
                {
                    source: '/:slug/viajes/',
                    destination: ':/slug/voyage/',
                    has: [{ type: 'host', value: `www.${process.env.NEXT_PUBLIC_HOST_ENV}example.es` }],
                },
                {
                    source: '/travel/:slug/',
                    destination: ':slug/voyage/',
                    has: [{ type: 'host', value: `www.${process.env.NEXT_PUBLIC_HOST_ENV}example.com` }],
                },
                // a lot more...
            ],
        };
    }
}

Remark

It feels very weird to be able to set Next config i18n.domains array synchronously using runtime env variables, but not being able to use runtime env variables in an async Next config rewrites or redirects function.
EDIT: I was wrong, actually all the next.config.js is at buildtime, our i18n.domains config was not OK but seemed to work 🙄

Questions

• Is it possible that someday we could use runtime env variables in Next config Rewrites & Redirects?
• How are you supposed to deal with advanced rewrites/redirects dynamicaly in the middleware without reinventing Routing?
  • Maybe there are some Next utils that we can use to match a route from a path and extract params, etc. ?
  • Or something else that may help us to generate such config without reinventing Router logic?

This is really annoying because Next.js's "buildtime config only" forces us to build a different assets build & Docker Image for each environment we have, this is insane... why would you do that? It is not logic at all to rely on env variables of a build/CI server, instead it should rely on runtime environment variables 😞

Thanks 🙏

[danikane]

I completely agree with this guy as my problems are identical.
This is another years old thread that's getting nowhere...
My guess is that the current rewrites implementation is as is by design and we can't expect any changes whatsoever.
Here's a similar thread:
#19078

The middleware approach is at best a workaround and very undesirable. Baked-in variables is a complete nonsense. I'd like to be able to build once, deploy anywhere...

This is their take on the subject:
https://nextjs.org/docs/pages/guides/environment-variables#runtime-environment-variables

• adopt the App router

[thomaaam]

I also want to add to this saying that not being able to determine locale configuration dynamically in run-time based on e.g. environment variables makes the use of Azure Web App swapping (Staging => Production) impossible. Right now I deploy the app without the use of swapping, which means minutes of downtime for every deployment, and it also takes away the neat feature of rolling back bad deployments by swapping back again.

My next.config.js has the following configuration for setting up locale and locale-based domains:

const subdomain = process.env.SUBDOMAIN;
const domainLocale = {
  [`${subdomain}.rootdomain.no`]: {
    locales: ["nb", "nn"],
    defaultLocale: "nb"
  },
  [`${subdomain}.rootdomain.se`]: {
    locales: ["sv"],
    defaultLocale: "sv"
  }
};

I want my NextJS app to be built with the same configuration for the subdomains dev, staging and www, meaning that the same locales apply to the top-level domains no and se. Note that I use a custom Node server, so my configuration is shared between build-time (NextJS app) and run-time (Node app setup).

So what ultimately want to happen here is that I can swap between staging and www without the need of a rebuild to reconfigure locales and domains. If I am missing something and this is possible with another approach, I am all ears!

[thomaaam]

FYI: I moved away from configuring rewrites at build time to using middleware, and it works like a charm, so this issue is no longer relevant for mye case.

[RihuaChen]

Can you give an example for using middleware as rewrites or proxy, thanks a lot, in next 13, I tried several methods, still not working for my proxy service.

[RihuaChen]

export const proxyMiddleware = (req: NextRequest) => {
  const destination = new URL(`${process.env.BFF_SERVER}`)
  const url = req.nextUrl.clone()

  url.host = destination.host
  url.protocol = destination.protocol
  url.port = destination.port

  return NextResponse.rewrite(url)
}

Pls use these middleware code for proxy, this works good in production