Using pathPrefix creates wrong hyperlinks in sidebar
vmarchesin opened this issue · 3 comments
Steps to reproduce
- Add
pathPrefix
config togatsby-config.js
- 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
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
.