Relative url bases sites.

[allanhortle]

I'd love to use Gatsby to generate small static elearning modules. One of the limitations I have is that the modules can only use relative url paths. Is it possible to config gatsby in such a manner so that each page of the site is bundled into one folder with all it's assets linked relatively? I'm okay giving up the full static rendering of each page and using a client side hash router instead.

[olizilla]

Support for relative links would be rad. If we had that we could publish gatsby sites to ipfs. You don't know what the path prefix is going to be until after it's added to ipfs as it's content addressed; your path prefix is the hash of the contents of the dir.

[KyleAMathews]

Hmm this sounds super interesting but hard perhaps in practice?

What kind of assets? Images?

Our JS code splitting for example, extracts out common modules (like react) into a commons.js bundle so that you don't have to keep downloading React over and over.

[allanhortle]

They can be anything you'd put on a website: Images/video/audio. The problem is that they are served up at an unknown url. e.g. /module/1234/. In the case of elearning modules that use the SCORM standard this is a design choice. The modules are meant to be shareable and not require any knowledge of the domain. Using a hash router gets around the problem of linking in app, but all asset links need to be relative to the entry point.

[stephenlacey531]

@allanhortle I'm dealing with the same issue here. I'd love to use Gatsby to produce SCORM packages but ran into the same issue with absolute paths.

[KyleAMathews]

I'd love to support this — but not really familiar with the problem. Is this something we can configure webpack to do for example? We'd need to make a change there + how we generate asset links in GraphQL & Markdown. Perhaps we could have a global useRelativeAssetPaths config flag.

Would love to hear the results of any research any of you have done.

[allanhortle]

I can't say I've done any research into the Gatsby code for a solution. Currently I'm using plain webpack to get around this. As far as that side goes you can set output.publicPath to ./ and file-loader has the option: useRelativePath: true.

[KyleAMathews]

Ah cool! That'd be part of the solution. Getting Gatsby's file outputs to do this as well would be relatively straightforward. Happy to guide someone through a PR if you'd like to volunteer.

[allanhortle]

Yeah for sure. Let me know any details you have outside of the CONTRIBUTING.md and I'll try to give it a crack sometime this week.

[KyleAMathews]

Nope that should be it. My preference would be for this to be all done in a plugin but i suspect it'd need to be a gatsby-config setting.

[BlinkyStitt]

Definitely interested in this. I'm hosting my sites on IPFS and all the static site generators I keep finding use absolute paths.

@allanhortle have you had any time to work on this? Or can you describe your workaround with plain webpack in more detail?

[allanhortle]

Sorry @WyseNynja I haven't had time to look into it at all. The webpack stuff is mostly this in your config:

output: {
    publicPath: './'
},

And then making sure you have loaders for everything so that it's all bundled together and there are no external urls.

[satazor]

For the people interested in making it work on IPFS, check https://github.com/moxystudio/gatsby-plugin-ipfs.

[KyleAMathews]

Due to the high volume of issues, we're closing out older ones without recent activity. Please open a new issue if you need help!

[wmitsuda]

I've found issues when generating sitemaps using the solution @satazor pointed out. It would be nice to have a "native" solution in gatsby that works out-of-box with any plugin.

My use case is trying to make a gatsby website available in IPFS.

[agentofuser]

Same here with Gatsby + IPFS. Would it be possible to reopen this issue?

[daydream05]

@agentofuser @wmitsuda were you able to make your site work on ipfs?

[olizilla]

See https://github.com/moxystudio/gatsby-plugin-ipfs