-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mappings working for gatsby develop
but failing for gatsby build
#6031
Comments
I would suspect this is hapenning in Try adding some console logging before you try to access if (!frontmatter.sponsor) {
console.log("this frontmatter doesn't have linked sponsor field", frontmatter)
} you should see in console which entry is at fault here |
ah. your description made me realize what i missed without the debugging. the mappings were working fine for all actual meetings, but the slug creation was too aggressive now that markdown files existed for things other than meetings. i added filtering so that slug creation that used the meeting template is now limited to meetings. i used a property that only exists on a meeting, which works but feels a bit hacky. since i'm still pretty new to gatsby and graphql, i'd be more than open to a suggestion if there is a more direct way to filter this. either way, thanks a lot for helping me track down the issue and for your work on gatsby. i continue to be impressed the deeper i get. |
👍 I'll close this, as issue was resolved |
yep that works. the only reason i didnt close myself was in case you had a recommendation for improving, but i didnt highlight the question very well:
what i have works to keep me moving and i can always improve as i learn, but if there is a recommended way, i'd love to learn tips like that early in my journey |
Maybe you can check how it is done on gatsbyjs.org - https://github.com/gatsbyjs/gatsby/blob/master/www/gatsby-node.js#L278-L311 we get parent node (which should be |
great, that sounds much more in line with what i was hoping for. i'll give that a shot for sure. thanks again! |
I have this working, albeit with painful behavior in develop mode. tl;dr Any edit loses the mapping for that node. For Markdown, each post can map to one more more topics, where both are in Markdown. Let's say PostA has, in its front matter: topics: ["topicA", "topicB"] where those map to a value in the front matter of some markdown documents. sourceNodes setups up the mapping and makes the nodes, gatsby-config "mapping" does the mapping, the Topic.tsx works fine listing all those posts with that topic. But if I edit any part of of post, the listing breaks. The query which grabs the topics fields, and extracts the front matter for the posts for the topic, returns all the front matter...except the one I just edited. Which is now null. Meaning, the mapping doesn't work for the edited target. Restarting This makes for a suboptimal authoring experience. I wondered if perhaps editing, from an immutability perspective, changed node.id but graphiql seems to have that be consistent. |
Description
my goal is to set up relationships between details in frontmatter of several different groups of markdown files. i was able to get this working for
gatsby develop
with the approach to mapping that i found here. however, when i rungatsby build
, it fails with a WebpackError due to failing to read a property ofnull
, which is one of the mapped relationships that worked undergatsby develop
. i was able to continue setting up more mappings that worked withgatsby develop
but failed the same way withgatsby build
.Steps to reproduce
data-structure
branchnvm install
npm install
npm start
(runsgatsby develop
). load the (early WIP, so no judging :) ) site in the browser and note that things are rendering w/o issuenpm run build
(runsgatsby build
). note the webpack errorExpected result
gatsby build
should complete successfully, resulting in a site that works the same as the one available fromgatsby develop
Actual result
Environment
File contents (if changed)
gatsby-config.js
:package.json
:gatsby-node.js
:gatsby-browser.js
: N/Agatsby-ssr.js
: N/AThe text was updated successfully, but these errors were encountered: