Best way to have basePath as runtime variable

[apotdevin]

Seeing that version 9.5 had the customizable base path out of the box I updated my project but started encountering various problems.

First it's a build variable so after creating a docker image, it can no longer be changed thus removing this customization option for any user that downloads the project's docker image.

After seeing this problem, I went back to how I had it setup before:

• having a basePath as publicRuntimeConfig in the next.config.js
• manually adding the base path to Link, the public asset src and the router push
• having an nginx configuration like this one:

location /basepath/ {
  rewrite ^/basepath(.*)$ $1 break;
  proxy_pass http://localhost:3000/;
}

and left the nextjs version at 9.5.

Wanted to see if anyone is having a similar issue? Maybe there's a better way to handle the basePath as a runtime variable that I'm missing on this last version?

[sigo]

I came across to the same need. Have you found any other solutions? I'd like serve this way nextjs exported app.

[apotdevin]

Hey, manually adding the basepath to different parts of the code was getting dirty and not working properly in later versions so removed it and went with the standard way of adding it as a build variable. To solve my issue with the docker images I now build two different images each with a different basePath. This doesn't scale at all for more basePaths but for now have only needed these 2.

[ElMoselYEE]

Has anyone come up with a way of doing something like this at runtime? I have a basePath use case as well, surprising that there's no way to provide runtime context.

[jholster]

I also encountered the same issue. Can't deploy the same build (image) to multiple environments with different basePaths. I wonder if it would be possible to get a PR accepted for runtime basePath?

[thinksurance-review]

I've faced same problem. Still no solution?

[kumarjai1]

I have a similar problem, anyone have an idea on how to tackle it? I would love to discuss and resolve it.
Thinking out loud here - is it not possible to obtain the pathname from the url at runtime and set the basepath + assetPrefix dynamically in next.config.js if the pathname is valid (checking for some liveness/readiness before setting the basepath/assetPrefix)

[gmotyl]

In my project there's one instance that serves multiple markets. Since each market has different basePath - it can't be setup in build time... seems like common problem and it would be nice if framework solves it for you...

[miteshbirru]

have you solved this issue, waiting for your reply.

[nictownsend]

Wanted to see if anyone is having a similar issue? Maybe there's a better way to handle the basePath as a runtime variable that I'm missing on this last version?

Hi all, I have a "workaround" for this based off @apotdevin answer . But I'd really love the community to tell me I'm making a big mistake (or making too many assumptions).

1. Use serverRuntimeConfig in next.config.js to pass a basepath via getConfig() in _app.tsx. This can be added into a ReactContext and appended to any href or src tags.
2. Use an eyecatcher (/@BASEPATH@) as assetPrefix in next.config.js. Then use sed at runtime to replace /@BASEPATH@ with process.env.BASEPATH || "" in generated css from next build.
3. Use a custom server (https://nextjs.org/docs/advanced-features/custom-server) with app.setAssetPrefix(process.env.BASEPATH || ""); so that any rendered HTML uses the right src for <link> or <script> tags.
4. In _app.tsx force server-side rendering withMyApp.getInitialProps = async () => ({ props: {} });

This feels "safe" for now, but I worry that there may be a later breaking change hidden in the roadmap.

[M3kH]

Wanted to see if anyone is having a similar issue? Maybe there's a better way to handle the basePath as a runtime variable that I'm missing on this last version?

Hi again, this is a current issue if you want to deploy multi tenant projects.

Currently we're exploring the following with next 12.3.0:

• We can't use basePath because is consumed at build time
• We're exploring assetPrefix since is runtime only and we process thought the config such as process.env.ASSET_PREFIX
• And we use middleware.ts to do rewrites of the paths.

Definitely feels fragile, and we're exploring the consequences.
But seems working.

For now the big hit, by looking at nextjs canary source, is that the basePath has more than few occurrences, this involves:

• Translations
• Links
• Images
• Public

[zetoke]

@M3kH have you had any success with the approach that you were going to use?

[M3kH]

So far so good, the approach above worked until a certain point, we had to work around couple of more stuff.
We faced much more need in having dedicated config injected, so the initial experiment wasn't enough.

What we did:

• We create our own config setup and injecting them into the runtime from the _document.tsx

import { publicConfig } from 'my-config';
...
        <script
          id="__CONFIG__"
          dangerouslySetInnerHTML={{
            __html: `
              window.__CONFIG__ = ${JSON.stringify(publicConfig)}
            `,
          }}
        />

• We then notice that we had to patch some internals, the most important __NEXT_ROUTER_BASEPATH to do it we grab the reference in the window by using the webpack.DefinePlugin in the next.config.js

  webpack(config, options) {
    config.plugins.forEach((i) => {
      if (i instanceof options.webpack.DefinePlugin) {
        if (i.definitions['process.env.__NEXT_ROUTER_BASEPATH']) {
          i.definitions['process.env.__NEXT_ROUTER_BASEPATH'] =
            '(typeof window === "undefined" ? global : window).__CONFIG__.BASEPATH';
        }
      }
    });
    return config;
  },

• assetPrefix is always set in the next.config.js which usually is resolve to something like process.env.BASEPATH

import { publicConfig } from 'my-config';
...
module.exports =  {
 ...
 assetPrefix: publicConfig.BASEPATH || '/',
}

One big side note are the Error pages, we couldn't get them working as they can't be disabled in SSG, this force us to implement a redirect, is not the prettiest but works.

[mumu1993]

any update?

[M3kH]

I've created a feature request #41746

[mrspence]

In the meantime: use env variables - here's what worked for me:

.env.development, .env:

NEXT_PUBLIC_BASE_PATH=/some-base-path

nextjs.config.js:

basePath: process.env.NEXT_PUBLIC_BASE_PATH,

Now anywhere else in your Next JS app, you can access the base path using process.env.NEXT_PUBLIC_BASE_PATH

[THEtheChad]

This is also not dynamic. NEXT_PUBLIC_ variables get inlined during the build step on any client code.

[blackbing]

import Router from 'next/router';

console.log(Router.basePath);

[Bingo1392]

I would love to see the answer for this question. I am facing an issue that I have to build an docker image and run it in multiple docker images with different basePath and assetPrefix.

[DiskCrasher]

Ditto.

[Afellman]

We need to be able to easily switch basePath via ENV var at runtime. I shouldn't have to have this var exposed during build time

[ats1999]

My Solution

• Keep a placeholder in place of basePath - ___APP_BASE_PATH__
• Replace your placeholder with actual values from build output

Keep Smiling 😊

[ram3shyadav]

I did this in .env

NEXT_PUBLIC_BASE_PATH=process.env.__NEXT_ROUTER_BASE_PATH || ''

[Southclaws]

Ran into this too which was a hard requirement for our distributed Docker image where end-users are not expected to build the Next.js app from scratch and require providing config via environment variables (12-factor-app)

To sidestep Next.js' weird fake environment variable string-replacement, I use global.process.env in conjunction with a <script> to provide a configuration that's isomorphic and available to the frontend and backend.

The script is injected here: https://github.com/Southclaws/storyden/blob/main/web/src/app/layout.tsx#L21-L31

One caveat here though: this script is not loaded when Next.js encounters an error or a not-found (so, loading error.tsx or not-found.tsx) so if you rely on API calls for error reporting, it would require yet another workaround.

For the backend side, we provide an isometric helper to get the config: https://github.com/Southclaws/storyden/blob/main/web/src/config.ts

It also might be possible to use instrumentation-client.js file convention: https://nextjs.org/docs/app/api-reference/file-conventions/instrumentation-client I've not yet confirmed is this also works for error.tsx or not-found.tsx

Hope this helps!