Use relative URLs instead of absolute #32216

@mikecardwell Other issues are talking about this. The solution is to use assetPrefix.

That is not a very good solution as it would require me to build one set of files to be served by a webserver, and then a different set of files to be accessed via a file:/// url. A better solution would be the one I described where relative URLs are used throughout.

@mikecardwell I meant that you can use assetPrefix to achieve your described solution (create relative paths):
assetPrefix: './'

But I still can't see why is it required to preview locally via file URI? Couldn't you use serve or any other http server locally?

Making the urls relative won't fix the issue. Since then you'd have issues when there's nested pages, pages/some-dir/some-route.js (some-dir/some-route route) would get a could not find some-dir/some-route/_next/*. The right solution is to use for example serve to serve the html files through a webserver. That would be a better test anyway right, since users will get the html served through a webserver 🤔

@timneutkens - Your example doesn't work because @blistok's solution was wrong and would not work. When I say to use relative URLs, I mean that each html page which is generated would know where it is relative to the content it is trying to link to. For example when generating "some-dir/some-route", it would know that it is 2 levels deep, and it would know that the _next directory is one level deep, so when generating that particular page of HTML, it would use "../_next/blah". When generating another page for the same site, it might need to use "../../../_next/blah". This isn't just the "_next" directory I'm talking about either, it's all resources, e.g. link tags etc.

As it stands, "next export" doesn't produce a website which can be served from anywhere, it spits out a website that can be served from a particular subset of URL structures.

Here is a real life example of a website where that is a problem: http://www.exim.org - That is a statically generated website. It also has a large number of mirrors - http://www.exim.org/mirmon/www_mirrors.html - Many of these mirror a website from a sub url. E.g http://mirror.easyname.at/exim/ - The mirrors are updated by simply rsyncing the static files from the source on a schedule. This setup could not work with the files that nextjs spits out, because they are not portable.

Here's another use case: I want to build a nextjs app which I can just export to disk, zip up and distribute it as an application for people to unzip on their desktops/laptops and open in their web browser using "File -> Open". I can't do that with next export as it stands, because everyone will be opening the project from a different directory.

HTML documentation that comes packaged along with the application in a .tgz... Step 1 for reading this documentation, install a web server?

If nextjs used relative urls then you wouldn't need to tell people who want to serve up their site on things like github pages to add assetPrefix to their nextjs configuration. It would "just work".

[edit] You closed this issue prematurely IMO. I hope that doesn't mean my response is ignored.

Support for exporting a static site with internal links and asset references all being relative urls would be rad for statically hosting next.js apps on ipfs or, as @mikecardwell explains, any situation where the site needs to be self-contained and can't assume a specific mounting path.

+1 Will be like, "woah, man" once Mike's ideas become reality.

@timneutkens I am re-opening this. It's causing Next.js apps that are routed through a Path Alias rule to return the incorrect hostname which leads to potential CSP issues, etc.

It would be nice to have a good solution for this.

@TooTallNate we use path alias for zeit/docs without any issues using absolute URLs. I really don't like to use relative URLs since they complicate things unnecessary.
The state is undefined when someone use a relative URL inside a component which used in multiple pages.

@arunoda The router could be extended with a function to allow you to look up the current path to the root of the app. Then people could just wrap such components in the withRouter HOC and then do things like:

<img src={ `${this.props.router.pathToRoot}/static/images/foo.png` }/>

Which would sometimes spit out <img src="./static/images/foo.png"/> and other times <img src="../../../static/images/foo.png"/> depending on the current URL.

Of course, people who are happy with absolute URLs can just continue doing what they're doing right now, but for all of the use cases which require relative URLs, a solution would exist.

I'd be totally happy with a manual solution to this like @mikecardwell suggests.

Gonna +1 this issue.

Perhaps this is a specific use case (but I have seen others complaining).

My situation is that I am running multiple nextJS apps in a Kubernetes cluster with a NGINX ingress module getting requests from an AWS ELB. Each app is assigned a namespace such as mysite.com/app1 or mysite.com/app2. The NGINX ingress is configured such that when a request is received on /app1, it forwards it to the root (/) of the container running app1 (because app1 is expecting requests on /).

To make links work (see: href), the NGINX instance adds a base element to the head of the page, so that each URL (such as going to /contact-us on a example page) is prepended with our base, hence we get /contact-us => mysite.com/app1/contact-us and everyone is happy!

This of course, doesn't work with nextJS as the paths are all absolute instead of relative (base only works on relative paths) and since this base is being added by NGINX on requests, it is difficult to guess the URL during build (auto deploy URLs/Machine Generated URLS).

Would love to see support for either base, relative paths, or perhaps a completely different solution!

Any solutions to this? I am running nextjs static export from cordova which doesn't have webserver and serves pages as file:// so need to have relative paths

I think the only current solution is to post process the exported HTML to modify the links.

Thanks, the main issue with pathanmes like '/' or '/home' imagine doing search and replace of string '/' not a pretty task

How it worked for me you can also give it a try.

Main points

1. Add next.config.js file with module.exports = { assetPrefix: './' } (you can have more properties in the module according to your code requirements )
2. Make change in package.json file in scripts with "build": "next build && next export"
3. Make changes to all next/link - Link herf value's (for eg. index page - earlier (href="/") after change (href="./index.html") and for all other pages like this earlier (href="/PAGE_NAME") after change (href="./PAGE_NAME.html")

--- imp

1. PAGE_NAME represent placeholder for your page name.
2. To access all your public folder content of next js for eg for image use src="./image.jpg" instead of "/image.jpg".
3. The "build": "next build && next export" in above Main point 2 will create a out folder with your build files that works ("build": "next build" that creates build files in .next folder won't work neither using next.config.js file with module.exports = { distDir: 'BUILD_FOLDER_NAME' } will not work)
   (BUILD_FOLDER_NAME is a placeholder)

I guess as of right now the issue is that the javascript code have no way of figuring out the base without extra configuration, after all the url are written as /xxx/yyy/zz instead of xxx#yyy/zzz, and because of that, it is difficult to figure out where the actual base path is just from the url itself.

In my case, this config helped:

module.exports = withPlugins([[withSass], [withImages]], {
  webpack(config, options) {
    config.resolve.modules.push(path.resolve("./"));
    return config;
  },
  basePath: "/xxx",
  assetPrefix: "/xxx"
});

We find ourselves in a similar situation to @tanishq-dubey, where some path flexibility currently keeps us from being able to migrate to Next.

Currently we package our React apps as Docker images which allow for the basePath to be set at container startup (via env var). This is possible with some pretty minimal base path trickery via our current stack (create-react-app, React Router, Express), but doesn't seem to be possible with Next short of either: A) leaving source in the image and making containers do a full re-build internally on startup if the basePath has changed or b) setting basePath to some unique token that a recursive sed run modifies as necessary before startup. If there is some cleaner option I'm overlooking I'd love to know, as both of those feel a little too dirty for us to consider. :)

If we could get past the base path hangup, our only other issue is more of a nitpick. Just that including the entire Next package in the image for serving the app feels pretty heavy at ~80MB uncompressed. Would be nice if the production server could be broken out into its own module, but maybe that's crazy talk. TBH I haven't researched the options much.

This feature would be great in Electron apps. In order to use Next.js with Electron in production, one would need to start a custom server on localhost, making it available in the browser as well, which is not always desirable. If this is implemented, we could just appWindow.webContents.loadURL('/path/to/nextExportDir'), completely eliminating the server overhead.

Currently facing this in my first react project as well. Are we on the same boat or is there a method / workaround for this in react?

I don't think there are any generally useable solutions/workarounds. I assume that, given the amount of demand for this functionality, and the lack of any movement on it in the 4 years this issue has been open, it's just too difficult for the devs to bolt on now. It should have been there from the beginning.

Kind of annoying situation honestly, react-router@v6 is lighting years ahead of next/router except that it is missing the FS convention

I'm running into this problem as well as I'm trying to figure out how to render my exported Next.js app within Electron.
I've come across a few options:

1. https://github.com/vercel/serve
2. https://github.com/sindresorhus/electron-serve
3. https://github.com/HaNdTriX/next-electron-server

Has anyone evaluated whether these options are able to solve this problem?

Commenting just to say that this is such an obvious default next.js should come with that I'm absolutely flabbergasted. Flabbergasted!

I have the same requirement for using file:// protocol to browser html pages offline, without any local web server.
Some people need this for testing, or for sharing the website to others through office network share drive (web server is not allowed) etc.
Most of the JamStack tools requires local web server for their experted static HTML, expect MkDocs I found so far.

My workaround is:

Instead of config assetPrefix in next.config.js, or using <a> instead of next/link, there is another workaround that using JavaScript to dynamically change each of the path in your HTML, when it detect is under file:// protocol.

Here is the example, when page is laded, the script will check the protocol, and iterate all of css asset links, duplicate another one with their relative path:

<script>
        if (window.location.protocol === 'file:') {
            const styleSheets = document.styleSheets;
            let head = document.getElementsByTagName('head')[0];
            for (let i = 0; i < styleSheets.length; i++) {
                let link = document.createElement('link');
                link.rel = 'stylesheet';
                link.type = 'text/css';
                link.href = `./${styleSheets[i].href.split('/').pop()}`;
                head.appendChild(link);
            }
        }
</script>

Please notice, the script will cause infinite loop if you append the link with a workable href that is found and already loaded

The same approach could also be applied to other assets or <a> href etc.

I'm working on a static Next.js site and ran into this issue today. Being new to Next and coming from a Jekyll background, I'm surprised this is still a problem after 5+ years, Jekyll handles this out of the box with minimal configuration tweaks or awkward workarounds.