Enable generating relative (as opposed to root-relative) URL websites

[agentofuser]

Summary

Currently, Gatsby users can set the pathPrefix property in gatsby-config.js to enable websites to be hosted on subdirectories of the root path, eg routes built using pathPrefix: "my-path-prefix" are rendered as /my-path-prefix/a-route/.

However, pathPrefix is taken to be a root-relative path (that is, one that starts with /), thus requiring the final hosting path to be known ahead of time.

The proposal is to enable compilation of websites with relative URLs to enable post-fact path composition.

Basic example

One way to enable this would be supporting something like:

module.exports = {
  pathPrefix: "./",
  // ...
}

Currently, doing this results in root-relative URLs starting with /./. With support for relative paths, it would generate relative URLs starting with ./, ../, ../../, etc. as appropriate.

Motivation

Allowing only root-relative URLs makes it impossible to compile websites that can be served from unknown future locations, such as elearning modules or IPFS websites like https://ipfs.io/ipfs/QmaR3y5xiWTD4U3zD74cn14SxXWU2Cnp4AEMGQQURXaHLh/.

In the latter case, the fact that the prefix contains a hash of the content of the website makes it impossible to self-reference in an ahead-of-time root-relative pathPrefix (there can't be cycles in a hashlinked graph).

Proof of concept

@satazor has come up with a nice hack in https://github.com/moxystudio/gatsby-plugin-ipfs/blob/master/src/gatsby-node.js where the pathPrefix is set to a known constant which then gets replaced post-build from the generated files.

I've added some hacks on top of that hack to account for the need for absolute URLs in RSS feeds and to fix the relative depth calculation in URLs loaded in the browser from gatsby-generated json files.

This hack of course probably misses many corner cases. In particular, it doesn't allow generating a resulting path prefix other than ./ like, for instance, ./my-blog/. It would be great to have this done within Gatsby, and I'd love to work on it if there is official interest in a PR.

ref: #2467

[olizilla]

Static sites are nice. Portable static sites are awesome. As it's possible to know the entire layout of the site at build time, it'd be great to allow users to generate sites that dont assume a path prefix but use relative urls that can work just fine on both a staging url like /<unique-id>/about and a production url like /about

[Exospheric]

Maybe these pages will help. I hope so. I use Racket/Frog but the same problem exists for any SSG on IPFS. I'm actually not a web expert and I had to spend a couple of days figuring out the nomenclature of parts of URIs. Racket output is different than most SSGs because output goes to site root and not a production subdirectory, so even source files are in the IPFS repository. That also means asset directories are siblings in site root.

But you'll see that I made the decision from the start to use IPNS to nail down the site hash. I knew that IPNS was the Achilles' heel because it can be slow. But it basically always works. I assume, and still hope, that IPNS will get better. The simplicity I get seems a reasonable trade-off for its sloth.

I have no idea how it will ever be possible to reference hashes of old versions of pages.

https://js.ipfs.io/ipns/QmZJBQBXX98AuTcoR1HBGdbe5Gph74ZBWSgNemBcqPNv1W/hosting-frog-on-ipfs.html

https://js.ipfs.io/ipns/QmZJBQBXX98AuTcoR1HBGdbe5Gph74ZBWSgNemBcqPNv1W/exactly-how-to-host-frog-over-ipfs.html

[cameron-martin]

Am I right in thinking that implementing this would remove the need for the pathPrefix config option?

[agentofuser]

@cameron-martin I guess it would still be useful in the cases where the user does want to have a root-relative url. In that case, pathPrefix could be /, or /my-prefix. Or, to keep backwards compatibility, my-prefix, with relative path requiring the explicit ./.

[cameron-martin]

@agentofuser In what scenario would people's sites behave incorrectly when using relative URLs, forcing them to instead use root-relative URLs?

[agentofuser]

@cameron-martin yeah I can't think of a reason why someone would need to or want to have root-relative URLs.

[MLukman]

Please consider implementing this feature.

[rbi]

Couldn't relative paths even be the default? I don't understand why this is always an issue with JavaScript Frameworks. When there is a way to make compiled apps work on any directory and even make it possible to make them work by just double clicking the index.html in the file explorer why not implement it that way?

What is the use case of using absolute paths and accepting configuration headaches and reduced flexibility?

[Exospheric]

I've had three months to deliberate on this issue. It's a bit of a mind bender for me but I will try to elaborate on the use case for root relative links as it relates to static sites posted on IPFS (hopefully, without going TL; DR).

even though I am not currently using Gatsby, I usually recommend it to most newbies, because the static site generator I use is written in Racket, which is hard and which has an enormous library.

my site exploits the availability of a site base address suffix of the form:

someuniversity.edu/~someuser/

where ~someuser holds either:

/ipfs/ContentID/
Or
/ipns/UserID/

the latter case is by far the easier to deal with but it has serious drawbacks in that IPNS is notoriously slow, and I don't see anyone who thinks it's going to get better.

the problem with hard coding the IPNS address immutable reference is that every single link hits IPNS every single time, which makes the user experience exasperating.

the other possibility I have entertained is to generate a throwaway repository that contains the previous CID, (let's call it CID[n-1]) and only use CID as a point of entry into CID[n-1]. but with only absolute addressing, this creates an infinite regression and can't work.

if root relative links were possible, as I have found in my experiments, either strategy could work.

if IPNS is used, it is only used as a point of entry one time because the browser knows the content ID after it is dereferenced from the User ID.

same for using CID and CID[n-1].

My site generator not was not built with this use case in mind.

somehow I have to figure out a way to hardcode the site base address as:

example.com/ipfs/CID/ (or example.com/ipns/UID/) and let the generator leave the internal links relative to that for the browser to compute.

[Exospheric]

I should mention that when using ipfs companion local gateway, example.com is automatically redirected to localhost. that might be an important secret.

[tschaub]

Bummer. It would be nice if it were possible to generate a portable static site – or otherwise generate a site without knowing ahead of time where it would be hosted. It looks like all the issues related to this have been closed. Does anyone know if the problem can be solved within Gatsby or if it would require upstream changes (e.g. to a router)?

[agentofuser]

generate a site without knowing ahead of time where it would be hosted

This seems such a basic need, I'm not sure what's keeping this from moving forward.

Would maintainers be willing to merge if someone put in the work?

[bitttttten]

I am also looking for a solution to this! Setting pathPrefix to . makes the URLs looks like:

<script src="/./webpack-runtime.123.js" />

And like others, I am looking to build a Gatsby site in Phonegap and blocked by this at the moment. Happy to help and give input if this will be something that gets merged :)

[nilocesar]

I work with applications for LMS, my clients only receive or zip the project (static) and place it in their hosting, so a solution with a totally relative path is needed. Does gatsby criteria any viable solution for this?

[tschaub]

Perhaps some hope in NTmatter@921b5f4.

[tschaub]

Also feels "not stale" to me. But I'm not actively using Gatsby (because of this issue).

[duckfev3r]

still no solution - the need for this is definitely still present.

[dandv]

@ewagstaff, @tschaub, @duelingbanjos - please see #25074 for a discussion on the auto-stale policy.

[cheshrkat]

This would be really helpful. My use cases are...

1. wanting to generate versioned copies of documentation for frameworks and APIs
2. wanting to generate a copy of the docs when we spin up pull requests

Path prefix can probably solve (1) but (2) changes too often for that to really be suitable.

example.com/gatsbydocs (imagine this is v3)
example.com/v1/gatsbydocs
example.com/v2/gatsbydocs
test.example.com/pr_123/gatsbydocs (could be any version)

...

Relative URLs would solve my use cases, although being able to dynamically pass in an optional prefix would also work. By the time I'm putting things into servers/containers I usually know the prefix and could pass it to gatsby build during CI.

[tschaub]

@cheshrkat - I think your two example uses are good. I would add a third: serving the same built resources from multiple locations. We have internal urls (e.g. internal.example.com/123/path/) that can also conditionally be exposed externally (e.g. www.example.com/path/). In this case, we can update the externally deployed version by configuring a reverse proxy with a new origin - without rebuilding or copying any of the resources being served.

[tvanantwerp]

This is a feature I really need right now. I've put a lot of time into a Gatsby site, only to discover I'm not going to be able to move forward because this isn't a feature. Now I'm having to think how I'll get around this...

I think I'll try something other than Gatsby for my next project. Too many gotchas like this.

[lucnap]

This feature is very important

[urvashi01]

Adding voice to the cause here. Much needed feature for abstraction.

[tschaub]

It looks like Hugo has support for a relativeURLs configuration option for this same purpose: https://gohugo.io/content-management/urls/#relative-urls

[github-actions[bot]]

[kachkaev]

bump

[cheshrkat]

Since this has been moved from Issue to Discussion I guess it's dead and buried 🙁

[ascorbic]

@cheshrkat On the contrary! We've moved all feature requests here, as it's easier to keep track of them when they're not mixed-in with bugs. They won't get auto-closed either.

[tschaub]

@ascorbic - What do you think is the next step for this type of Idea / Feature Request? Should someone put time into a formal RFC?

[CosPie]

still no solution now?

[neilchaudhuri]

We have come across this ourselves. It's fine that the Gatsby team doesn't consider this a priority, but can they or anyone suggest a workaround based on, for example, environment variables and server configuration?

[JavierPiedra]

Not a workaround with gastby but removing gatsby and using pure react with PUBLIC_URL env var does the job.
https://create-react-app.dev/docs/advanced-configuration/

[j-a-h-i-r]

I think I'm also facing this issue. I am using GitHub actions to deploy a site to <my-domain.com>/path. The index page is working correctly but other links are broken. For example, clicking on a link in the index page takes me to <my-domain.com>/url instead of <my-domain.com>/path/url.

I'm using https://github.com/peaceiris/actions-gh-pages for deployment. Does anyone know how to fix it? Thanks

[harryhaigh]

Is there an update on this issues? This is one of GatbysJS biggest downfall. It's obvious so many people need relative paths yet the GatsbyJs team continually do nothing to support this feature.

[yondr-agency-15]

Checkout this plugin: https://github.com/moxystudio/gatsby-plugin-ipfs

[tejasfulkar]

This fixes images but links still remain broken :(