GraphQL Error Field "image" must not have a selection since type "String" has no subfields.

[dajocarter]

Description

I've been getting this error everytime I deploy to Netlify and most times in development. The only way I seem to be able to get around it in development is to delete node_modules and yarn install, and even this doesn't work every time. If I do get around it in development and I stop gatsby develop, the next time I run it, it comes back and I have to repeatedly delete node_modules and yarn install until it works again.

My directory structure looks like

src
├── posts
│   ├── some-post
│   │   ├── some-image.jpg
│   │   └── index.md

my post frontmatter looks like

---
title: "Some Post"
image: "./some-image.jpg"
draft: false
...other fields
---

my graphQL query looks like

query IndexQuery {
    posts: allMarkdownRemark(
      limit: 3
      filter: {
        fileAbsolutePath: { glob: "/**/*/src/posts/**/*.md" }
        frontmatter: { draft: { eq: false } }
      }
      sort: { fields: [frontmatter___date], order: DESC }
    ) {
      edges {
        node {
          excerpt
          frontmatter {
            slug
            date(formatString: "MMMM D, YYYY")
            image {
              childImageSharp {
                sizes(maxWidth: 660) {
                  ...GatsbyImageSharpSizes_tracedSVG
                }
              }
            }
            title
            tags
          }
        }
      }
    }

Environment

Gatsby version: 1.9.202
Node.js version: v8.1.3
Operating System: OSX

File contents (if changed):

gatsby-config.js:

plugins: [
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `posts`,
        path: `${__dirname}/src/posts`
      }
    },
    {
      resolve: `gatsby-transformer-remark`,
      options: {
        plugins: [
          {
            resolve: `gatsby-remark-images`,
            options: {
              maxWidth: 728
            }
          },
          {
            resolve: `gatsby-remark-responsive-iframe`,
            options: {
              wrapperStyle: `margin-bottom: 1.0725rem`
            }
          },
          "gatsby-remark-prismjs",
          "gatsby-remark-copy-linked-files",
          "gatsby-remark-smartypants"
        ]
      }
    },
    `gatsby-transformer-sharp`,
    `gatsby-plugin-sharp`,
    ...other plugins
]

package.json:

"dependencies": {
    "gatsby": "^1.9.202",
    "gatsby-image": "^1.0.37",
    "gatsby-plugin-sharp": "1.6.30",
    "gatsby-transformer-sharp": "^1.6.19",
    ...other packages
}

gatsby-node.js:

exports.createPages = ({ boundActionCreators, graphql }) => {
  const { createPage } = boundActionCreators;

  return new Promise((resolve, reject) => {
    const postTemplate = path.resolve("./src/templates/post.js");
    ...other templates

    resolve(
      graphql(`
        {
          posts: allMarkdownRemark(
            filter: { fileAbsolutePath: { glob: "/**/*/src/posts/**/*.md" } }
          ) {
            edges {
              node {
                frontmatter {
                  slug
                  draft
                }
              }
            }
          }
          ...similar queries
      `).then(result => {
        
        if (result.errors) {
          console.log(result.errors);
          reject(result.errors);
        }

        result.data.posts.edges.forEach(({ node }) => {
          if (!node.frontmatter.draft) {
            createPage({
              path: `/posts/${node.frontmatter.slug}/`,
              component: postTemplate,
              context: {
                slug: node.frontmatter.slug
              }
            });
          }
        });

        ...similar page creation
      })
    );
  });
};

[pieh]

Check for case differences in filenames: f.e. image: "./some-image.jpg" vs image: "./some-image.JPG"

[dajocarter]

There are no case differences. The only differences are in file type, image: "./some-image.png" vs image: "./some-image.jpg", and empty fields in some of my drafts, image: "".

[pieh]

@dajocarter delete fields with empty strings completely and keep fields that actually point to a file - when we construct schema types we check if string does look like a path and empty string does not so we don't transform it to File link

[dajocarter]

@pieh That fixed my issue. Thanks for your help!

[cedricdelpoux]

@pieh It should be specified somewhere. It's a strange behavior if no image in frontmatter is transformed to sharp node if there is an empty value hidden somewhere in a file

[cedricdelpoux]

@pieh Could you tell me where the "check if string does look like a path" in the gatsby code ? I did not find it

[pieh]

@xuopled https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/types/type-file.js#L28

Problem here will be that we compile all nodes to create representative data sample. So it will see that string is empty - but we can't tell if that's just string field or file field at this point, so we would need to adjust compiling down example node to prefer non-empty strings over empty strings for generating representative object (somewhere here https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/data-tree-utils.js )

[PatrickResponsive]

I had this issue, what fixed it for me was taking all the images out of the folder, doing a git commit and putting them back with the correct .JPG or .jpg

Hope that helps someone

[nbw]

I used the correct .jpg or JPG, but it still didn't work. So I ended up recloning my repo, npm install, gatsby dev, and it was fixed.

[amanrathore10]

Thanks mate, it fixed my error too.

[kpennell]

Darn, what a terrible fix.

[DSchau]

@kpennell the issue is that these are incredibly hard to reproduce and vary based on machine setup.

Oftentimes this is caused by some type of Sharp error out of our control, so if you can reliably reproduce this we'd love to take a look.

[kpennell]

@DSchau

Wondering if things to check are:

1. check one has the right plugins
2. image files are there
3. paths are spelled right
4. path cases are right
5. something else?
6. delete node modules and public and try to reinstall?
7. Check media_folder and public_folder are right?
8. Use relative path plugin or something with fmImagesToRelative(node)

I made an SO question here: https://stackoverflow.com/questions/55736780/what-causes-the-string-has-no-subfields-image-error-in-graphql-gatsby

Anyway, sorry to be one more person with this issue.

[unyo]

I recently upgraded from gatsby@^2.1.0 to @^2.15.33, using netlify-cms. In order to bypass this error for certain fields, in addition to checking to make sure you don't have any imageFieldName: "", you also have to make sure there are no empty container arrays.

eg. for

  section {
    image {
      publicURL
    }
  }

  section:
    - image: /img/something.jpg
    - image: /img/something2.jpg
       fieldName: 'hello'

you need to make sure you don't have any section: [] in your .md files, otherwise the latest version of gatsby seems to throw this error during build.

[Nezteb]

@nbw's solution of restarting the development environment worked for me.

It seems like when updating markdown files while gatsby dev is running, the GraphQL schema isn't regenerating with the updated content. Or at least, it's updating it slowly and sometimes thinking that certain fields are empty. 🤷‍♂

[olegKusov]

@nbw's solution of restarting the development environment worked for me.

It seems like when updating markdown files while gatsby dev is running, the GraphQL schema isn't regenerating with the updated content. Or at least, it's updating it slowly and sometimes thinking that certain fields are empty. 🤷‍♂

i restarted my dev server with "gatsby clean" and it doesn't help me. Look like bug

[jacknugent]

Edit: This comment has incorrect information. In my example, I set image to be of type String, which won't get me an image. I should have set image to File @fileByRelativePath

---

After hours debugging this, I decided to make the simplest possible example to show how broken this error truly is. I forked the official gatsby-starter-blog and did nothing but add an "image" property to the frontmatter for the salty_egg.jpg image already in the project. I then included that "image" property in gatsby-node.js. Even then, running npm install and gatsby develop, then going to localhost:8000/___graphql shows that Frontmatter.Image is of type String, not File. You can try cloning my gatsby-starter-blog fork and see if you get the same results.

A few other things I made sure to do that didn't fix the issue:

• Put gatsby-transformer-sharp and gatsby-plugin-sharp at the top of the gatsby-config.js plugins, before any gatsby-source-filesystem declarations. This is suggested on Gatsby's troubleshooting page. Note: the gatsby-starter-blog does not do this currently.
• Make sure the naming is right. I used the salty_egg.jpg file already in the repo, which is correctly referenced in the markdown. I used the same naming convention as the Gatsby docs suggest (i.e. something like image: salty_egg.jpg.
• delete .cache and node modules and reinstall. I confirmed this does not work. Again, go to my forked repo and see for yourself

If I were you reading this, I would recommend giving up on this functionality before you waste any more time. If even a simple implementation forked off of Gatsby's official starter blog doesn't work, I don't know what would.

[leochoo]

This bug is consistently happening across all different machines. Can this please get addressed?

[LekoArts]

@jacknugent Please note that your error is here: https://github.com/jacknugent/gatsby-starter-blog/blob/master/gatsby-node.js#L109

You're forcing the image to be a String so it's expected that you don't get an image.
It has to be File @fileByRelativePath. Please edit your comment as your information is incorrect and gives the false impression that this doesn't work.

[jacknugent]

@LekoArts thank you for pointing that out. I confirmed that solution works, and I added an edit to the top of my comment.

I must have overlooked how the docs for preprocessing external images does exactly what you suggested.

I think Gatsby's troubleshooting for this issue should include using File @fileByRelativePath. I went through many issues (example #1, example #2, example #3, example #4, example #5) and never found this suggestion.

[jvhellemondt]

@dajocarter delete fields with empty strings completely and keep fields that actually point to a file - when we construct schema types we check if string does look like a path and empty string does not so we don't transform it to File link

This actually fixed it for me... Time was wasted.