gatsby: [gatsby-source-filesystem] File content missing during build

Preliminary Checks

Description

I am upgrading from Gatsby 2 to Gatsby 4 and have run into an issue that is not present in v2. File content from gatsby-source-filesystem that is available during gatsby develop is not available during gatsby build. When I read the content of a file that needs to be embedded into a page (via a pageQuery, but useStaticQuery behaves identically), it works fine in develop.

pages/index.js:

export const pageQuery = graphql`
  query {
    example: file(name: { eq: "example" }) {
      id
      lastUpdated: modifiedTime
      name
      ext
      internal {
        content
      }
    }
  }
`;

files/example.html:

<p>success</p>

gatsby-config:

  plugins: [
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `html`,
        path: `${__dirname}/src/files`,
      },
    },
  ],

gatsby-node.js (as adapted from this comment):

exports.onCreateNode = async ({ node, loadNodeContent }) => {
  if (node.name !== "example") return;

  // Ensure Gatsby loads the item into memory so that its
  // content becomes available in the GraphQL File node
  try {
    const nodeContent = await loadNodeContent(node);
    console.log(node);
  } catch (error) {
    console.error(error);
  }
};

Result in develop:

{
    "example": {
        "id": "6fec6f1f-32b7-5da1-b235-0563112c93bc",
        "lastUpdated": "2022-01-26T14:54:38.306Z",
        "name": "example",
        "ext": ".html",
        "internal": {
            "content": "<p>success</p>\n"
        }
    }
}

Result in build:

{
    "example": {
        "id": "6fec6f1f-32b7-5da1-b235-0563112c93bc",
        "lastUpdated": "2022-01-26T14:54:38.306Z",
        "name": "example",
        "ext": ".html",
        "internal": {
            "content": null
        }
    }
}

This was working fine in v2. We need this to work because we are pulling remote html during build time that is embedded into the static html via dangerouslySetInnerHTML.

Reproduction Link

CodeSandbox: https://codesandbox.io/s/elastic-mccarthy-m6qgy Repo: https://github.com/jdahdah/gatsby-transform

Steps to Reproduce

  1. If you check out the repo locally, run yarn install && gatsby develop. If you use the CodeSandbox example instead, it does this step for you.
  2. You will see that the box is filled with the word “success”.
  3. Run gatsby clean && gatsby build && gatsby serve (or if you’re on CodeSandbox: yarn run gatsby clean && yarn run gatsby build && yarn run gatsby serve).
  4. You will see that the box is empty.

Note that the console.log(node) that is written by gatsby-node.js during the build does contain the correct data. The console.log(data) from pages/index.js does not. So the data is available during onCreateNode, it’s just not reaching the page query for some reason. See also the follow-up https://github.com/gatsbyjs/gatsby/issues/34605#issuecomment-1026668361.

Expected Result

I expected the build to include the file contents just like it does during the build. internal.content should result in "<p>success</p>\n".

Actual Result

internal.content is null.

Environment


  System:
    OS: macOS 12.1
    CPU: (10) arm64 Apple M1 Max
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.2 - ~/.nvm/versions/node/v16.13.2/bin/node
    Yarn: 1.22.17 - ~/.nvm/versions/node/v16.13.2/bin/yarn
    npm: 8.1.2 - ~/.nvm/versions/node/v16.13.2/bin/npm
  Languages:
    Python: 2.7.18 - /usr/bin/python
  Browsers:
    Firefox: 95.0
    Safari: 15.2
  npmPackages:
    gatsby: ^4.7.0-next.0 => 4.7.0-next.0 
    gatsby-source-filesystem: ^4.6.0 => 4.6.0 
  npmGlobalPackages:
    gatsby-cli: 4.6.0

Config Flags

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 8
  • Comments: 21 (12 by maintainers)

Most upvoted comments

~I have the same issue, specifically it happens with images using gatsby-transformer-remark. All images are loaded correctly in development, but the production build crashes while compiling with Cannot read properties of null (reading 'dir'). I have an 8 core Apple M1, I updated to macOS 12.2 overnight and the issue still happens~

Edit by @LekoArts: This was fixed in https://github.com/gatsbyjs/gatsby/issues/34693

~Same here. I get the message Cannot read property 'dir' of null On builds since updating to Gatsby 4 and Gatsby-plugin-image 2.6 yesterday.~

Edit by @LekoArts: This was fixed in https://github.com/gatsbyjs/gatsby/issues/34693

Same here ! Encountered the issue with gatsby@^4.6.0, but when downgrading to gatsby@4.5.4 everything is working as expected.

Great, thanks for your code snippet (future Google users will thank you). I’ll mark this issue as closed as the issue you’re seeing is fixed by using the proper API (createNodeField) 👍

The other issue is trying to use internal.content - this is really meant as “memoization” and not something you should reach directly - if you want actual content, you should probably use createNodeField with value being set to await loadNodeContent(node) and whatever field name you’d like to use (it will be later available as node.fields.<yourFieldName>

Hey @jdahdah - workaround for this can be done via:

exports.onCreateNode = async ({ node, loadNodeContent }) => {
  if (node.name !== "example") return;

  // Ensure Gatsby loads the item into memory so that its
  // content becomes available in the GraphQL File node
  try {
    const nodeContent = await loadNodeContent(node);
+   // to ensure we update a node in LMDB we create dummy child node,
+   // and use `createNodeField` to ensure LMDB is updated
+   actions.createNodeField({ node, name: `contentLoaded`, value: true });
    console.log(node);
  } catch (error) {
    console.error(error);
  }
};

loadNodeContent currently doesn’t update LMDB (it only mutates node in memory). We can to update node in lmdb by using createNodeField action which should ensure content is stored in lmdb

Same here ! Encountered the issue with gatsby@^4.6.0, but when downgrading to gatsby@4.5.4 everything is working as expected.

Hmm, I’m not getting consistent results here. If I do a gatsby develop followed by a gatsby build with gatsby@4.5.4, it works. If I do a gatsby clean && gatsby build (which is closer to a CI environment) it still breaks as described above.

Edit: in fact, the behavior is identical to gatsby@4.6.0. Are you clearing the cache before you build with 4.5.4, @timurrustamov?