+1. It seems Next doesn't have great support for being exported and served on a path that isn't the root, which is really frustrating.

any update to resolve that?

I'm finding I can't use output: 'export' in my next.config.js to output a static build, without getting errors locally.

If I don't add any assetPrefix, then all of my files in a local static build don't link properly.

In my index.html, the scripts/css/fonts etc all have src attributes like this:
src="/_next/static/chunks/webpack-6207a2ddf87fc86b.js". I need it to be src="./_next/....... to work.

I have tried adding assetPrefix: './', in the config, but then I get this build error:
next/font error: assetPrefix must start with a leading slash or be an absolute URL(http:// or https://)

Why won't NextJS let me add the ./!?

I understand this would likely work on a server if deployed there, but you'd think I'd be able to check it locally.

Turns out you can run a simple web server from your terminal python3 -m http.server 3000.

• cd into the folder where your static build lives.
• Run python3 -m http.server 3000
• Go to http://localhost:9000/

I know this doesn't fix the initial question, but this worked for me wanting to check the build locally.

I can only confirm the above works on a mac. But getting a simple web server running from a command is an easy google.

Any updates on this? I'm not sure why won't you allow to have ./ as prefix when we are anyways doing an export?

Seems like we have to replace /_next/... to ./_next/... manually in out folder using replace all command and hope that this issue will be fixed in the future 🤔

@TorryDo seems like this. Do we have any script to do this? I think someone mentioned all-relative can be used but it's not customizable

Also running into this issue. I need to export a static build that uses a relative path, ./ to upload the build on our CMS, but I get the error "assetPrefix must start with a leading slash or be an absolute URL(http:// or https://)"

has there been any progress on allowing relative paths as the asset prefix? Thanks!

@geekysam7 @csdiehl , I use this script to change /_next/ to ./_next/ in Linux and it works fine. Gist

Hi @TorryDo, Thanks for share it.

But I have some problem here, o paste the .sh in my project but after buil o got this message "find: out: No such file or directory" I paste the .sh in main directory together with my package.json

Should I need to do any more special thing? Thanks!

@henriqpohl did you add output="export"? here is the docs. "out" is the default output directory of generated static site

@TorryDo I found the problem... You are using Linux and I'm using Mac OS, in that case the .sh command should be like code below:

LC_ALL=C find "out" -type f -exec sed -i '' 's/\/_next/\.\/_next/g' {} +

Now, everything is working for me.

Cheers!

thank you @henriqpohl ! that worked for me on Mac OS. I also had to make a couple more changes in the post-processing script:

# replace paths in the CSS
LC_ALL=C find "out/_next/static/css" -type f -exec sed -i '' 's/.\/_next\/static/\.\./g' {} +

# fix the regular expressions that are not escaped - add a \ before any / if there isn't one there already
LC_ALL=C find "out/_next/static/chunks" -type f -exec sed -i '' 's/\.\\/_next\\/data/.\/_next\/data/g' {} +

After that, it worked! hope this helps someone else trying to serve a Next.js static build from any root

Are there any updates about fixing this build issue?

@emilkrebs follow what @TorryDo share on Gist, I modified little bit and work perfect for me, I leaved here my modified also you can found and read in some comments above.

If people were using ./ just fine before but can't anymore, then this is a breaking change. Yes I can manually run scripts but why not just let the old functionality be as well?

For Next.js to have such an issue is really funny to me. I am working on implementing the above scripts but why should we need to do it? I saw someone close similar issue by saying:

I recently closed a similar issue to this one as it would involve a lot of work for very minimal gains.
#6059 (comment)

What a joke!! I am trying to automate deploys of different sites within 1 S3 bucket as a means of building my pipeling to intake more customers. This is not a "very minimal gains" issue 🙄

The nextjs team is not going to solve this problem??? What’s amazing is that I already had this kind of problem after building without changing anything after installation. It’s such a high-star project.

So will this be fixed? Why enforce http/https prefixes? I run into this weird problem while building an electron application and using static exports. I wish next.js would let go of the restrictions.

This was super frustrating to me as well, and unfortunately I needed to do it in Windows which made things a lot more complicated. I put up a gist that takes @TorryDo 's idea and converts it to PowerShell commands for those of us forced to work in Windows.

@TorryDo 's idea is working but my images is not loading and when I login the dashboard it show white blank.

Unfortunately, I'm having the same problem with nextjs15.

Seeing the same issue, hopping for a quick fix since aside from this Next15 has been great,

Lol! It should be fixed asap 🤦‍♀️ OMG, these workarounds with a script.

I am also facing the same issue,this needs to be fixed asap

I had a similar issue with my portfolio website. The generated website code is stored in docs and the github pages publishing source option is set to docs.

The following set of steps resolved my website rendering issue:

1. Delete the old static website code from repo. (In my case delete docs folder)
2. Set both assetPath and basePath to '' in next.config.mjs.
3. Build the website and store the generated code to out folder (npm run build)
4. Renamed the out to docs.
5. Added an empty file .nojekyll to docs: source
6. Pushed the changes to github. The website is rendering properly now.

I can resolve this issue by changing all the assets' locations in the root file.

Any updates? Disappointed to meet such problem...
Finding and replacing all "/_next" to "./_next" does solve this problem... yet it is not elegant...

Replacing /_next with ./_next seems a good workaround but it doesn't solve the deeper problem.

As above, RSC resource isn't properly loaded and it could not be fixed using something replacing /_next to ./_next

The method I use is to directly cancel the limitation in node_modules and do that every time before next build.