pathPrefix and SSR@runtime does not work together

[jbebe]

Preliminary Checks

• This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
• This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions

Description

When using the Gatsby v4 SSR@R feature of gatsby serve the usage of pathPrefix makes the runtime fail to prefetch urls.

In packages/gatsby/cache-dir/loader.js there's a line:

return this.doPrefetch(findPath(pagePath)).then(() => {

This findPath call removes the path prefix from pagePath, doPrefetch gets an invalid url and this corrupts the runtime cache, so if I click on any link, the framework loads up the 404 page.

This - of course - only happens if doPrefetch is called. If I use <a> tags in my components instead of <Link>, then the problem goes away, and also the SPA feature of Gatbsy... 😄

Since pathPrefix cleaning is part of findPath for a very long time (around 4 years?) I think the issue here is that someone didn't think about how SSR@R and pathPrefix trimming plays along.

Reproduction Link

https://github.com/jbebe/gatsby-prefetch-issue-repro

Steps to Reproduce

Steps to Reproduce:

1. Create a gatsby project (latest for me was 4.11.3)
2. Add any pathPrefix to the gatsby-config
3. Create a [...].tsx file that can process any URL
4. In that [...].tsx file, create a server side rendering component
5. Create a <Link> tag on the index.tsx page that references /any-random-url
6. build & serve with prefix-paths
7. During page load, prefetch will throw errors for the 3 Links, upon clicking a link, it won't take you to the page but instead gives 404 error

Steps to get rid of the bug: (pick any and it will work)

• Change SSR@R component to generated, static content
• Don't use pathPrefix
• <a href="withPrefix(...)"> instead of <Link to={...}>

Expected Result

SSR@R components/urls with pathPrefix should work like simple, pre-generated content with pathPrefix.

Actual Result

Prefetch handles SSR@R urls differently, it strips the prefix from the url, so it won't point to anywhere.

Environment

System:
    OS: Windows 10 10.0.19043
    CPU: (12) x64 Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
  Binaries:
    Node: 16.9.1 - C:\Programs\node\node.EXE
    npm: 7.21.1 - C:\Programs\node\npm.CMD
  Languages:
    Python: 3.10.2 - C:\Programs\Python\python.EXE
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (100.0.1185.29)
  npmPackages:
    gatsby: ^4.11.3 => 4.11.3

Config Flags

pathPrefix: '/blog'
--prefix-paths

[rogeriocolonna]

Not only SSR but DSR too.

[jbebe]

Please show any sign that the bug is being validated or something. We really need to use path prefixed links with gatsby serve!

[rogeriocolonna]

I need too

[rogeriocolonna]

3 months, 3!
No response.

[jbebe]

I think I summon my coworkers to weigh in on this bug because that's ridiculous.

[pieh]

Confirmed, will be opening PR with fixes and some tests soon

[tyhopp]

Hi @jbebe and @rogeriocolonna, we published the fix to gatsby@4.20.0-next.5. Please try it out if you can, hopefully this will unblock you both. This will land in the next minor release (gatsby@4.20.0) on August 2nd.

[rogeriocolonna]

Yes, is working fine!
Thank you

[rogeriocolonna]

Thank you! Em seg., 25 de jul. de 2022 às 23:24, Ty Hopp ***@***.***> escreveu:

…

Hi @jbebe <https://github.com/jbebe> and @rogeriocolonna <https://github.com/rogeriocolonna>, we published the fix to ***@***.*** Please try it out if you can, hopefully this will unblock you both. This will land in the next minor release ***@***.***) on August 2nd. — Reply to this email directly, view it on GitHub <#35406 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WEOK2YXHNKTNNVVOIXNDVV5D7RANCNFSM5TGCKCWQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>