Use relative URLs instead of absolute

There are many tags in the HTML which NextJS generates which contain absolute URLs. For example:

href="/_next/blah"

I’ve added selenium + chrome headless testing to my Next project, and it works fine when I test http://localhost:3000, but when I do a next export, and then try to to test file:///home/user/project_dir/out/index.html, all of those absolute links are broken.I.e, it tries to fetch file:///_next/blah instead of: file:///home/user/project_dir/out/_next/blah.

If I post-edit the generated HTML to make those links relative, then it all works fine.

I need to be able to run my tests against the static files which are generated by export to ensure that they have been generated correctly before publishing.

I suspect this is also an issue when people simply wish to run their nextjs application from a location other than the root of their website.

• I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

Tech	Version
next	v3.0.1-beta.15
node	v8.1.3
OS	Debian 9
browser	Google Chrome 59.0.3071.115

[mikecardwell]

@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.

[tanishq-dubey]

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!