johno/gatsby-theme-documentation

Using pathPrefix creates wrong hyperlinks in sidebar

vmarchesin opened this issue · 3 comments

Steps to reproduce

  1. Add pathPrefix config to gatsby-config.js
  2. Build using gatsby build --prefix-paths (Gatsby docs)

Expected behavior

Paths should have the path prefix added once.
e.g. /endpoints would become /my-path/endpoints after build.

Actual behavior

For assets and links inside .mdx pages inside /docs the path is added once, but for links created in sidebar.mdx the path is added twice.
Actual result: /my-path/my-path/endpoints

Actual generated example

src/gatsby-theme-documentation/sidebar.mdx

<li><div class="css-70qvj9">
<a class="css-1dbh7qa" href="/my-path/my-path/">Api</a>
</div></li>
<li><div class="css-70qvj9">
<a class="css-1dbh7qa" href="/my-path/my-path/installation">Installation</a>
</div></li>
<li><div class="css-70qvj9"><a class="css-1dbh7qa" href="/my-path/my-path/endpoints">Endpoints</a>
</div></li>

gatsby-config.js

module.exports = {
	siteMetadata: {
		title: 'API Documentation',
		description: 'Docs for API',
	},
	plugins: [
		'gatsby-theme-documentation',
	],
	pathPrefix: 'my-path',
}

I've got the same issue, did you come up with a workaround @vmarchesin ?

@skeet70 I couldn't pinpoint the issue so I decided on a workaround instead. Inside src/gatsby-theme-documentation/sidebar.mdx if instead of /endpoints you use ./endpoints it will generate the following HTML:

This

- [Endpoints](./endpoints)

Becomes this

<a class="css-hash-something" href="/my-path/./endpoints">Endpoints</a>

It doesn't look pretty but the browser is able to resolve /./ correctly and it works fine at the end. So during the build step all the links inside sidebar.mdx are relative to the docs folder instead of src/gatsby-theme-documentation, which makes this possible. So whenever you want to write /something inside sidebar.mdx just write ./something instead and it should work.

This does not solve the issue, however. It's merely a workaround.

This issue seems to be related to ChristopherBiscardi/gatsby-mdx#377 - i.e. it's occurring specifically because the nav-link component is returning a Link. I was able to apply the same workaround described in that issue, by shadowing nav-link.js with a copy where I've replaced

with to={to.replace('/insertPathPrefixHere', '')}. If I had more experience with Gatsby, I'd try to figure out how to have nav-link.js look up the path prefix specified in gatsby-config, instead of having to replace insertPathPrefixHere with the actual prefix inside nav-link.js.