[gatsby-transformer-javascript-static-exports] Usage with `gatsby-image`

[fabe]

Hi! I'm using gatsby-transformer-javascript-static-exports to pull in data from pages into my layout:

layouts/index.js:

export const pageQuery = graphql`
  query IndexQuery {
    site {
      siteMetadata {
        title
      }
    }
    allJsFrontmatter(
      filter: { data: { isWork: { eq: true } } }
      sort: { fields: [data___date], order: DESC }
    ) {
      edges {
        node {
          data {
            error
            title
            path
            cover {
              childImageSharp {
                sizes(maxWidth: 1400, quality: 95) {
                  ...GatsbyImageSharpSizes_withWebp
                }
              }
            }
          }
        }
      }
    }
  }
`;

pages/page.js:

export const data = {
  isWork: true,
  subtitle: 'Subtitle.',
  title: 'Title.',
  date: '2017-04-01',
  path: '/page',
  cover: './cover.png',
};

This worked in the past (and still works on production/netlify). However, now locally it gives me these errors on both gatsby develop and gatsby build:

The GraphQL query from /src/layouts/index.js failed

        Errors:
          GraphQLError: Path must be a string. Received undefined,GraphQLError: Path must be a string. Received undefined,GraphQLError: Path must be a string. Received undefined,GraphQLError: Path must be a string. Received undefined,GraphQLError: Path must be a string. Received undefined 

It seems to me that the layout somehow doesn't receive the correct path for the cover data item (which referencing an existing image in the same folder). This is possibly related to #1819, no answers there.

I'm on node 8.5.0 (also tested with 6.9.2), and gatsby-cli 1.1.20. Tried reinstalling and rebuilding everything, but no change.

Thanks!

[cwgw]

@fabe, were you able to find a solution for this?

I'm experiencing the same behavior. What's puzzling is that I get inconsistent results. It works and then it doesn't, and all I did was stop and restart the development server.

If you've gained any insight into the problem, I would love to hear about it. Thanks.

[fabe]

@cwgw Unfortunately not. I had to query every image inside the layout and manually pass it down to the pages from there. Code is here:

https://github.com/fabe/site/blob/master/src/layouts/index.js#L33
https://github.com/fabe/site/blob/master/src/layouts/index.js#L98

[cwgw]

@fabe thank you for responding and for sharing your code. (You've got a good looking site, by the way).

I created a small repo intending to isolate the problem. My example site seems to work properly, until it doesn't. I'm at a loss.

Would you be willing to reopen this issue in the hopes that it gets some more attention?

[fabe]

@cwgw Thanks!

[m-allanson]

@cwgw thanks for the repo, that was very useful! I had a good dig around and can confirm the problem you're seeing. I'm not sure how to fix it, but can consistently recreate the error.

This seems to be a caching issue - here's what I've found:

Running rm -r .cache && yarn run develop will always work. Any subsequent changes without restarting the develop command will also work.

Quitting and restarting yarn run develop will cause GraphQL errors. However, the initial bootstrap of yarn run develop won't log those errors to the console. Running the query in http://localhost/__graphql will display the error. Subsequent file changes will log the GraphQL error to the console.

So it seems that when the bootstrapped data is created fresh, everything is fine. But whenever the bootstrap is loading data in from the .cache directory, there are problems. Maybe this is an issue with parsing cached JSON data? @jbolda @KyleAMathews any thoughts on how to fix this?

[pieh]

I will take a look at this later today. Probably will have to starting debugging from gatsby-transform-sharp resolver or in core with File related inferring stuff where I would assume this error is thrown and examine why does it happen.

[pieh]

Uhm, sorry guys, it seems like it was me who broke things - at least stuff that I could reproduce with @cwgw repro repo. Opened pull request with fix for that - #4013 .