Replies: 11 comments 8 replies
-
Just sharing another workaround: https://gist.github.com/u8sand/db56c9db4afc381c3716e9a60f96b638 It might break in future versions because of NextJS's slightly different handling of the root path. In short, you build with an entrypoint of Presumably the same trick could be used for other environment variables. It's not ideal but beats rebuilding at runtime.. |
Beta Was this translation helpful? Give feedback.
-
Any news on this topic? |
Beta Was this translation helpful? Give feedback.
-
Same question. Seeing people with similar issues trying to deploy path-agnostic docker containers. |
Beta Was this translation helpful? Give feedback.
-
Hello, any updates on this issue? Highly relevant for me |
Beta Was this translation helpful? Give feedback.
-
@M3kH thank you for the workaround but it looks like this fixes partially the problem. At least with next 13.4.4 |
Beta Was this translation helpful? Give feedback.
-
Are there any concrete plans to implement that? |
Beta Was this translation helpful? Give feedback.
-
It really surprises me that Next.js doesn't support such a basic feature. It only supports application hosted in the root of a (sub)domain. This is really limiting. |
Beta Was this translation helpful? Give feedback.
-
Would love to see support added for this 👍 |
Beta Was this translation helpful? Give feedback.
-
Sorry, how can i add definition in _document.tsx? |
Beta Was this translation helpful? Give feedback.
-
Hi, do you have any update on this? We are facing the same issue right now (next: 14.0.4). I am searching the internet for a solution with surprise to find nothing. Or am I missing something? Thanks in advance. |
Beta Was this translation helpful? Give feedback.
-
Hi, any news on this from the next.js team? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the feature you'd like to request
Currently
basePath
is consumed during build step although this value could "easily" be changeable at runtime.This can enable more flexibility during the deployment without the cost of
build * basePath
.Describe the solution you'd like
Modifying the current behaviour of
config.basePath
might introduce a breaking change.An option could be to add a config (maybe as
env
as:process.env.NEXT_RUNTIME_BASEPATH
) and make it accessible inwindow.__NEX_DATA__
asbasePath
.Such to have the option to do:
process.env.NEXT_RUNTIME_BASEPATH || process.env.__NEXT_ROUTER_BASEPATH
.Which with
webpack.plugins.DefinePlugin
could be declared as such"process.env.NEXT_RUNTIME_BASEPATH": "window.__NEXT_DATA__.basePath"
.Reference:
process.env.__NEXT_ROUTER_BASEPATH
Describe alternatives you've considered
Currently my workaround is:
process.env.BASEPATH
and expose to the client aswindow.__CONFIG__.BASEPATH
and to the server asglobal.__CONFIG__.BASEPATH
.process.env.__NEXT_ROUTER_BASEPATH
webpack definition inDefinePlugin
:_document.tsx
the definition ofwindow.__CONFIG__
Beta Was this translation helpful? Give feedback.
All reactions