gatsby: Hot reloading error: "path" argument must be of type string
Hot reloading in gatsby develop gives this error in my project. Hot reloading sometimes works despite the error (as in, I see the error in the console window where I ran gatsby develop, but the website in browser appears to hot reload and work just fine). This error appeared after I updated some (mainly Gatsby) npm dependencies. Stack trace is giving me no ideas on how to debug this. Is it a Gatsby bug?
Note that this error only comes up on hot reload. So I can run gatsby develop just fine as long as I don’t make any changes to any files. I can also build just fine.
[ { TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined
at assertPath (path.js:39:11)
at Object.resolve (path.js:1085:7)
at findLinkedFileNode (/.../node_modules/gatsby/dist/schema/resolvers.js:208:47)
at resolveValue (/.../node_modules/gatsby/dist/schema/resolvers.js:223:108)
at /.../node_modules/gatsby/dist/schema/resolvers.js:220:10
at process._tickCallback (internal/process/next_tick.js:68:7)
message:
'The "path" argument must be of type string. Received type undefined',
locations: [ [Object] ],
path:
[ 'allMarkdownRemark', 'edges', 0, 'node', 'frontmatter', 'cover' ] } ]
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 8
- Comments: 17 (11 by maintainers)
Commits related to this issue
- fix(gatsby): Reset graphql runner on certain node events Hot reloading is broken on certain configurations due to node materialization. Child objects in the node model are not updated when a node is ... — committed to sdobz/gatsby by sdobz 4 years ago
- fix(gatsby): Reset graphql runner on certain node events (#20586) * fix(gatsby): Reset graphql runner on certain node events Hot reloading is broken on certain configurations due to node materializa... — committed to gatsbyjs/gatsby by sdobz 4 years ago
A fix by @sdobz totally works as a dirty temporary solution. The error stops breaking gatsby, and you just need to hit refresh to see your changes (not ideal, but whatever, it’s better then restarting gatsby every time I save a file)
This is still a pressing issue though, rendering
gatsby developunusable for, well, development. It would be really cool if some one from the core team addressed it soon 😎Just wanted to note that this issue still exists in gatsby 2.18.5.
I’m seeing this behaviour as well and am here to test if/when needed. 😃
Ok, update: Comment above is correct - just more details on why this happens: In our node tracking code, we check if node is being tracked by using “tracked nodes” list that contain node IDs: https://github.com/gatsbyjs/gatsby/blob/95e908e3605eb2a0a240801f6c8ac5677ba9d6d7/packages/gatsby/src/schema/node-model.js#L336-L339
So when node is being updated (preserving its ID), we don’t track new node.
This problem is not visible in page/static queries because we reset the entire “Node model” instance (which removes/resets list of tracked nodes and bunch of other things related to
Materialization) in https://github.com/gatsbyjs/gatsby/blob/95e908e3605eb2a0a240801f6c8ac5677ba9d6d7/packages/gatsby/src/query/index.js#L349-L362 (graphqlRunneris object that have instance of "Node model, so resetting runner also resets used “Node model”)We could do the same for
graphqlfunction being used in gatsby-node APIs (includingcreatePages) - https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/bootstrap/graphql-runner.js (I just did dirty test and it seems to fix the issue).But this raises question - we have multiple unrelated “Node model” instances which potentially cause duplicate work that those “Node model” instances do - maybe there should be single “Node model” instance that will reset itself when needed so graphql runners don’t need to care about this detail (and also this could avoid potential duplicate work) - this is tricky issue and I think we should first fix it by resetting graphql runner used in
gatsby-nodeAPIs (similar to development query runner queue)/cc @freiksenet
@pieh could you share the dirty fix? I’m wallowing around in code I don’t understand looking for a place to do additional node tracking when a node is hot reloaded. Is this the right track? What files should I look in to get a handle on the hot reload lifecycle?
I have this behaviour and it’s becoming a bit frustrating. Mine it’s related to my “hero” image inside markdown files (not mdx):
By the way, just few days ago the error was more detailed, since it was related to “hero”. It said something like:
The "hero" argument must be of type object. Received type undefinedThis is the error now:
this is my graphql query under
gatsby-node.jsfileAlso I’m here to test if needed
So what I found is that the markdown front matter is getting confused as a ContextualNodeModel. So when you run Path.resolve(args), it is getting the front matter object, which doesn’t have the ‘dir’ attribute. I’m going to throw up a PR for the fix.
I’m interested in looking into this. @pieh , Mind if I poke around and see if I can resolve the issue?