Gatsby: Uncaught TypeError: t.replace is not a function (A page wasn't found for "[object Object]")

Created on 16 Feb 2018  路  11Comments  路  Source: gatsbyjs/gatsby

Description

I'm getting the following browser error on a production site generated by Gatsby.

A page wasn't found for "[object Object]"  loader.js:136 
Uncaught TypeError: t.replace is not a function
    at T (loader.js:144)
    at Object.getResourcesForPathname (loader.js:318)
    at o (production-app.js:85)
    at Object.onClick (index.js:204)
    at r.handleClick (Link.js:50)
    at Object.l (react-dom.production.min.js:26)
    at Object.invokeGuardedCallback (react-dom.production.min.js:25)
    at Object.invokeGuardedCallbackAndCatchFirstError (react-dom.production.min.js:25)
    at h (react-dom.production.min.js:30)
    at m (react-dom.production.min.js:32)
react-dom.production.min.js:27 

The error doesn't show up when the page first loads, but it does whenever I click on any of the internal links (all of which use Gatsby Link). This in turn causes the site to react way slower when navigating the site. Oddly enough I don't have this problem during development (the Links work as intended there), but only in the production site itself.

I have worked in a couple of Gatsby sites already and never had this problem before, so I have no idea what I'm doing wrong this time.

Environment

Gatsby version: 1.9.158
Node.js version: 8.9.3
Operating System: Ubuntu 16.04

Actual result

Whenever I click on any of the links the previously described error pops up and the site takes way longer to load the new page.

Expected behavior

The site should navigate to the linked route quickly and without any errors (just as it does in the development site.)

...

Most helpful comment

I wonder if it's related to this? https://github.com/gatsbyjs/gatsby/pull/3407

All 11 comments

Can you recreate the issue on a local build of the site? e.g. if you do gatsby build and then gatsby serve.

Hi @m-allanson ,
Yes, unfortunately, I'm having the exact same issue with a local build. I have also tried disabling some Gatsby plugins which I hadn't used on other sites before, but the result is always the same. Any idea of what the underlying problem might be?

Hmm. As a baseline try deleting your node_modules, .cache and public directories, then reinstall and rebuild.

Your error is coming from loader.js, if you're comfortable digging in to the code you could set up gatsby-dev-cli and have a look around at what that [object Object] is.

Alternatively if you can post an example repo I can have a look?

I wonder if it's related to this? https://github.com/gatsbyjs/gatsby/pull/3407

I had the same issue but it resolved when I updated Gatsby from ^1.9.102 to 1.9.203.

@KyleAMathews @m-allanson

I'm currently getting this issue only in production. Not when I build and serve locally. I have deleted my node_modules, .cache and public folders.

Gatsby: 1.9.238
Node: 8.9.4
MacOS: 10.13.3

@fpoumian did you find a fix for this?

Hey guys, it seems like a gatsby-link related issue. We were using 1.6.34, upgraded to 1.6.39 and encountered with this problem. Downgrading to 1.6.34 resolved.

I think there's an argument mismatch on the function chain triggered by react-router -> gatsby-link -> loader.js

@altayaydemir This didn't seem to work for me. Here's my package.json. Please let me know if you see any other issues. This is keeping me from pushing anything to prod.

update: This downgrade did work. I was still using ^1.6.39 in my package.json

@KyleAMathews Looks like the update to allow an object for "to" prop in https://github.com/gatsbyjs/gatsby/pull/3407 correctly updated the production only block on Line 142 to only send the path/pathname
https://github.com/nsimonson/gatsby/commit/d458fe72e35951c951d699e62cf311652fb952a8#diff-f0712f4b9f6079d8d9ba1ea7fa2c95d5L142

But was then reverted back to passing the whole state with this update for adding to history https://github.com/gatsbyjs/gatsby/pull/3802

https://github.com/gatsbyjs/gatsby/pull/3802/files#diff-f0712f4b9f6079d8d9ba1ea7fa2c95d5L160

which seems to be what is causing the loader.js to throw this log error only in built versions

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!

Was this page helpful?
0 / 5 - 0 ratings