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!

[cap-mfm]

I've done exactly the same, by injecting env vars using a <script> tag. Sucks that after all these years we still have to fight against next.js for such basic issues.

[Southclaws]

to be fair this is not strictly a next.js issue, they just haven't provided a solution to a problem that's present in full-stack architectures in general.

I understand what Next.js is trying to do with the text-replacement-based environment variables at build time, but it's not quite a 12-factor-app style solution for the larger more traditional deployment approaches - and it doesn't work at all for distributed Next.js apps (apps that end-users acquire from an open source product provider such as myself and don't build from source)

the core issue is that there is no such concept as an "environment variable" in the browser as there is in an operating system like windows, mac or linux. So passing process-level information into the browser requires some additional steps.

I would like to see Next.js tackle this with a built-in solution that does not rely on a hacky (imo) build-time text replacement - though I am glad they offer an escape hatch with global.process.env.

Generally, it's never a good idea to bake in configuration variables, such as sensitive secrets, to the actual application binary (yes, a Next.js app isn't strictly a "binary" but it's effectively the same as compiling a C program to an .exe file - and you'd never put your API keys or database passwords into the binary itself via compiler arguments)

Ultimately, it ties the compilation environment to the runtime environment, which is fairly backwards in terms of modern software deployment methodologies.

[cap-mfm]

I generally agree but you're mixing stuff up a bit IMHO. Configuration variables != sensitive secrets in the first place. Also, simply injecting those variables into the window global scope would be fine, and I don't get why I have to do that myself when Next.js could provide me with a well-supported approach (you're still playing with fire, hoping that the variables are set BEFORE anything else that depends on them runs its logic). This can be easily done, but I had to come up with it myself, as it's currently undocumented, and makes me NOT sleep well at night knowing a new minor version could totally break it.

[Southclaws]

Configuration variables != sensitive secrets

In this case, the same applies, I'm not recompiling my entire codebase just to change a configuration variable.

But yes I have the same fear, so upgrades happen a lot less often on 3 Next.js apps I manage as we're already used to things breaking on minor version bumps. Not really sure semantic versioning is even worth the façade any more haha

[THEtheChad]

This should actually be straight forward from a framework perspective. You would simply inject a synchronous script into the head that added your variables to a global object (possibly window). This would ensure that the values are ready before any code needing them is run.

There is technically a process.env that is set to an empty object in the bundle nextjs builds (at least on older versions). There's nothing stopping them from tacking on NEXT_PUBLIC_ values to that object. Then it wouldn't matter where your code ran (server/client), you would be accessing the values the same way.

The script that's injected would need to be re-evaluated for every page load which I think is the reason they don't do this. Or, at the very least, be re-built every time you start the server. This is actually the method I used for my own implementation where I leveraged instrumentation to generate the file on server startup.