Use relative URLs instead of absolute

[mikecardwell]

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

[slowdub]

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

[mikecardwell]

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.

[slowdub]

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

[timneutkens]

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 🤔

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

[olizilla]

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.

[binary64]

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

[TooTallNate]

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

[arunoda]

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

[mikecardwell]

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

[olizilla]

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

[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!

[Yuripetusko]

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

[mikecardwell]

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

[Yuripetusko]

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

[msabramo]

This is really unfortunate. The requirement to use absolute URLs for assets prevents the Build Once, Run Anywhere promise of Docker from being realized. If you build a Docker image using built/exported Next.JS code, you end up with an image that only works when the app is hosted at a specific path. It is easily broken once you put it in an environment where it sits at a different place in the URL hierarchy, which is very common thing to do because people often want to have a reverse proxy that routes to different apps based on their path prefix.

[raeperd]

I am of the exact same opinion. In this respect, it is difficult to say that nextjs fully supports Docker.

[Leonardll]

i am facing the same wall as well. I have deployed my next app on fleek, everything is fine on the home page but others pages are breaking after refresh with an error message that says the path is incorrect.

[PatrickAlphaC]

Having similar issues with other decentralized hosting solutions like arweave. My IPFS stuff is working great though (cuz my IPFS stuff is really small).

[PatrickAlphaC]

Ended up getting it to work... by manually going through my exports and replacing them with relative imports.

[talentlessguy]

@PatrickAlphaC it didn't work for me. Some styles and fonts fail to load by replacing to relative URL

[rwxguo]

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.

[csianglim]

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.

[DmacMcgreg]

Just had to urgently re-write an entire NextJS app project in Create React App with React Router because of this issue. file:// based routing is definitely still a thing with some large clients that distribute their app offline using secure intranet systems. Huge blow to the project, since we wanted to use a CMS with it using SSG, and this won't be possible with CRA.

Would be a great addition for NextJS to have some sort of config to handle this type of use case.

Also, this would work for simple electron builds, which we build a lot of for conferences where we have to pass off a single executable to the conference team to run and display on a television.

My opinion is that if Vercel is going to present NextJS as the best and universal way to build a react app, then it should support these valid use cases as well, not only the ones that directly benefit their business model. Ultimately, we are still your customers using vercel for various apps, but we have to build these types of apps as well. And if that can't be done, then we have to look for alternatives and consider just making all of our apps using those alternatives.

[benrudolphWSP]

Yes, especially government entities. Still very much a thing with them.

How did you go about converting to a React app? Was it easy? I'm in a bind and a client is beating down my door wondering why I can't make this work since the previous site did. I thought I was pushing this project forward moving to Next.js but simply not the case in this scenario.

[herbig]

[olizilla]

it'd be great if this were fixed in nextJS. In the meantime, the recommended way to fetch websites over IPFS is now to use a subdomain gateway like dweb.link where your site would be available at https://<cid>.ipfs.dweb.link. Putting the cid in the domain allows you to use / as the base URL for your site, and you avoid sharing an origin with every other website on that gateway. see: https://docs.ipfs.tech/how-to/address-ipfs-on-web/#subdomain-gateway

[olizilla]

for simpler static sites that don't rely on js for navigation, like those that hugo or eleventy would generate, you can run https://github.com/olizilla/all-relative on your generated output to convert all links in the html and css to their relative equivalent.

[herbig]

thank you @olizilla this is super helpful, I'll look into both these

[benrudolphWSP]

@mikecardwell Did you ever find a solution? I'm in the same boat where the site is being distributed via zip file and ran locally by opening in Windows Explorer. Total nightmare scenario as I previously had it working on a plain vanilla HTML/CSS/JS site and client is wondering why I can't make it work. Is it easy to convert project to a react app?

[mikecardwell]

I provided a simple solution 5 years ago in this comment - #32216 (comment) but that one requires some small changes to NextJS its self, which nobody has ever taken up.

So, I've just chosen not to use NextJS for projects where it doesn't work.

[DmacMcgreg]

You'll might just have to convert all the pages to React Router and CRA or Vite if you want a quick solution. It might take a few hours depending on the size of the app.

…

On Tue, Aug 15, 2023, 5:24 PM Ben Rudolph ***@***.***> wrote: Yes, especially government entities. Still very much a thing with them. How did you go about converting to a React app? Was it easy? I'm in a bind and a client is beating down my door wondering why I can't make this work since the previous site did. I thought I was pushing this project forward moving to Next.js but simply not the case in this scenario. — Reply to this email directly, view it on GitHub <#32216 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAY5LZ3TZFVFCXH6XJG66YLXVPLJJANCNFSM5VYIEUBQ> . You are receiving this because you commented.Message ID: <vercel/next. ***@***.***>

[dagoss]

+1 from me. I'm also running into this issue where I need to provide the client with a zip file that contains the application as standalone html/css/js and I can't control where or how it is deployed.

[mariotacke]

Just ran into this extremely annoying problem as well. Are there any plugins that could do this sort of transformation automatically? If this is possible through plugins, could you refer me to the relevant code sections?

[MimusSD]

Oh man is there no workaround for this? I can't even post-process the HTMLs because I have links in some CSS stylesheets to some media

[Otis-xp]

I wanted to package nextjs as an electron application, but nextjs couldn't export using relative paths, so the css and js files couldn't be found on the page of the packaged electron application

[benhansen-io]

I used logic similar to the following to get around this issue in an electron app:

  protocol.handle('file', (request) => {
    const url = request.url;

    const startOfNext = url.indexOf("/_next/");
    if (startOfNext == -1) {
      // Do not modify the request
      return net.fetch(url, {bypassCustomProtocolHandlers: true});
    }
    // Until nextjs can output static files that can be loaded from a directory (see https://github.com/vercel/next.js/discussions/32216)
    // we can either copy our files into the root directory or do this interception here to add the out directory.
    const new_url = [url.slice(0, "file://".length), app.getAppPath(), '/', REPORT_DIR, url.slice(startOfNext)].join('');
    return net.fetch(new_url, {bypassCustomProtocolHandlers: true});
  });

[gaurav21r]

@benhansen-io Great work but could you provide some context? Did you put this in the main process? Is protocol an export from electron ?

[benhansen-io]

That code is in the index.js of my electron app inside a

app.whenReady().then(() => {
...

})

and yes protocol is an electron export.

const { app, BrowserWindow, dialog, shell, protocol, net, contextBridge, ipcMain } = require('electron');

[ftm1337]

hi, when we deploy a static site over github pages, it works with normal relative urls
but the same repository doesnt work on vercel.
Our goal is to enable "Downloadable Websites" for OFFLINE USAGE. It would be helpful if vercel can mention that its incapable of handling "simple" websites properly and caters only to rich websites that require paying for servers (either financially, or expending financial resources to teach non-tech people (>99% of current humans) about "serving websites with a webserver".

got told this just now by a volunteer building disaster relief content. i dont mean to be dramatic, but i hope you see their point. a simple solution would be simply enable a Framework Preset for static simple pages and Not "build" them. would also save some resources for vercel. or maybe just point that vercel is not able to support such pages and refer people to a competitor like github pages ;)

[bymagnum]

Export NextJS to the folder where Electron looks at when building a project or during development, you will get static files. Next, add your own scheme, for example, 'app', register it. Run your app fully. That's the whole solution.

const scheme = 'app';

protocol.registerSchemesAsPrivileged([
        { scheme, privileges: { standard: true, secure: true, supportFetchAPI: true  } }
]);

const mainWindow = new BrowserWindow(browserWindowOpts);

mainWindow.loadURL(scheme  + '://localhost/index.html', loadOpts);