Gatsby 4 - Updates, Breaking Changes & Deprecations

[pragmaticpat]

In case you didn't know, we're planning the next major version of Gatsby for Q4 of this year! We're bringing some exciting new features that provide

• faster builds for medium to large sites, and
• increased dynamic capabilities of Gatsby ( yep, we're talking about server side rendering! )

Major versions afford an opportunity to deprecate and remove legacy behaviors. Our goal is to provide you all with ample notice to address these changes in advance of Gatsby 4 so that your projects are ready, day one!

Certainly let us know if you have any questions / concerns with items you see on these lists, or if you think of features related to items in these lists that we may need to consider, but are not listed. Thanks!

View the Migration Guide for all changes

[tlgimenes]

Hello!

I was reading the part of server side rendering and I wanted to share one thing I have always tried to do with Gatsby. One thing I have always tried to do was to reuse the Gatsby's graphql server in a lambda function so that I can do some dynamic queries. One use case would be in ecommerce. Imagine you have an ecommerce with 5 millions products and you want to generate one a portion of these products during SSG, and you want to make the rest be client-side rendered. Doing this is possible due to dynamic routing, However, you loose the graphql server and need to create a lambda function to your ecommerce provider and sometimes the shape of the product data is different from the graphql fetched part and from the lambda function. If the gatsby graphql server was available during serve time, it would be really nice since we would be able to share the same shape of data and avoid doing these data transformations outside of the graphql layer

[tujoworker]

Would it help if it was available inside Gatsby functions? (Despite your setup then needs to be able to run functions)

[davidpaulsson]

Yes!

[angeloashmore]

With the decoupled data layer in Gatsby 4, I wonder if this is possible now. Kind of like making the GraphQL server available at a constant endpoint.

You may be interested in the React 18 demo from Ward Peeters (https://www.youtube.com/watch?v=xPM7MhoaZY4). It shows how you may be able to render parts of the page statically while keeping others server-rendered. I don't believe this is possible in Gatsby 4 today, but may be available in a future release.

[wardpeet]

We're aware, but the GraphQL server doesn't scale that well yet. Source plugins and transformers can do a lot of heavy tasks. We need to make sure we can guard plugin authors against making "suboptimal" resolvers before opening this to the world.

[angeloashmore]

Node mutation/creation in custom resolvers

Description of the change This is something we discussed for a while. People usually do this to defer expensive things like file downloads. But we should come up with some alternative solution for them ideally.

Without coming up with an alternative solution before launch, this change likely will cause start up times to increase significantly. The pattern of downloading files in a resolver is used in gatsby-source-prismic (idea taken from gatsby-source-shopify) to defer downloads until queried. This means only files that are queried are downloaded, which, depending on the site, could be a small portion of all the available files.

This includes images and files like PDFs provided to a user's CMS.

If I understand correctly, this change means calls to gatsby-source-filesystem's createRemoteFileNode must happen upfront in sourceNodes. Plugins can implement a user configurable option to turn file downloading on and off, but this is usually an all-or-nothing option.

Is it possible to implement a lazy-fetching system with the File GraphQL resolver? The createRemoteFileNode call can happen upfront which creates a node with minimal data (URL, ID, etc.). The field resolvers could then lazily fetch and cache the file.

Without a system like this, I worry the progress made in making Gatsby's startup and builds quicker will be diminished.

[vladar]

This is a good point. The tricky part is file node invalidation when content changes in the remote (so that gatsby could re-run queries affected by this change on warm builds). Currently gatsby relies on md5 digest of file content (stored in internal.contentDigest field) for files. But if we create placeholder nodes - we won't be able to know the digest upfront unless the backend provides it.

I am curious how you would deal with it in Prismic? Do you have a digest for each remote file at the backend which we can use in sourcing? Or maybe you use content-addressable URLs?

In general, I think the suggested approach makes sense but will require some support from the backend to make it work correctly with Gatsby.

Edit: after some thinking - another big problem is that the transformation step is currently eager: happens when a node is created. So lazy file placeholders will also require a lazy transformation pipeline. It is like async vs sync functions in JS (explained in detail in "what color is your function" article). As soon as one node becomes lazy (async), all transformers that support this type of node must also be lazy (async).

So we'll have to adjust all transformers too to account for such a scenario. It is not impossible but something we need to carefully think about first.

[angeloashmore]

Hey @vladar, thanks for the detailed response.

Specifically for Prismic, each media content URL contains a UUID and is treated as immutable (i.e. users cannot replace the file or edit the URL). This should be enough information to create the content digest using just the URL.

This strategy wouldn't work for any API that does not have immutable URLs. WordPress, for example, allows replacing a file while keeping the URL, or even just editing the filename.

gatsby-source-filesystem appears to be using a set of metadata to produce a content digest rather than reading the actual file. Maybe this concept can be reused for third-party data, provided the source has specific-enough metadata?

gatsby/packages/gatsby-source-filesystem/src/create-file-node.js

Lines 25 to 31 in 66d9243

	const stats = await fs.stat(slashedFile.absolutePath)
	let internal
	if (stats.isDirectory()) {
	const contentDigest = createContentDigest({
	stats: stats,
	absolutePath: slashedFile.absolutePath,
	})

(Edit: I just looked closer at that code and it only uses metadata to create a content digest for directories. Files are actually read to produce an MD5 hash.)

---

Re: transformers - Yeah, that's tricky. I assume this worked previously because onCreateNode would run when a lazy node was created even within a resolver?

I don't know the transformer API well enough to comment on this, but I understand the magnitude of the implication.

(Btw, that's an awesome article. Thanks for linking it!)

---

For now, gatsby-source-prismic will implement a shouldDownloadFile plugin option that lets users determine if a file is eagerly downloaded. It was removed in the latest version of the plugin, but we'll have to restore it. This time, however, the function will be provided with enough data to accurately determine if a file is downloaded (such as filename, object field path, etc.).

[vladar]

Specifically for Prismic, each media content URL contains a UUID and is treated as immutable (i.e. users cannot replace the file or edit the URL). This should be enough information to create the content digest using just the URL.

It means you're doing it right 👍🙂

This strategy wouldn't work for any API that does not have immutable URLs. WordPress, for example, allows replacing a file while keeping the URL, or even just editing the filename.

Technically it is possible to encode a time-based expiration strategy in contentDigest (i.e. use the current week of the year as a digest). Or come up with extensions to older CMSes that will track changes to media files and send them in batch on warm builds to update the contentDigest of all modified files.

So we can potentially have lazy files with some additional support from the backend. The biggest challenge is transformers.

gatsby-source-filesystem appears to be using a set of metadata to produce a content digest rather than reading the actual file. Maybe this concept can be reused for third-party data, provided the source has specific-enough metadata?

The snippet you've posted is for directories. Files rely on a hash of the file contents:

gatsby/packages/gatsby-source-filesystem/src/create-file-node.js

Lines 37 to 46 in 66d9243

	} else {
	const contentDigest = await md5File(slashedFile.absolutePath)
	const mediaType = mime.getType(slashedFile.ext)
	internal = {
	contentDigest,
	type: `File`,
	mediaType: mediaType ? mediaType : `application/octet-stream`,
	description: `File "${path.relative(process.cwd(), slashed)}"`,
	}
	}

Re: transformers - Yeah, that's tricky. I assume this worked previously because onCreateNode would run when a lazy node was created even within a resolver?

Yes, onCreateNode is directly bound to createNode action call (at least currently). Probably exactly because of this issue.

[f-kottek]

Hey folks,

idk if this is the right place for this, but we recently ran into a weird (caching?) issue with remote file nodes.

---

EDIT:

It turns out, I might have been somewhat wrong with this! I dove deeper into the issue and found some other potential issue.
See: #34456
Keeping this up because it might still be helpful for someone.

---

Linked article image nodes, created with createRemoteFileNode, get lost after rebuild

I'll outline the scenario with some pseudo-code briefly.
During build, article data JSON files get pulled from an API. The interesting parts look somewhat like this:

{ 
 thumbnail_url: "https://example.com/th1.jpg", 
 article_images_source: [
   {
    image_url: "https://example.com/art1.jpg"
   },
   {
    image_url: "https://example.com/art2.jpg"
   }
 ]
}

Following the migration guide we did this to pull in and link these images to the article-node:

(short description)

1. fetch all articles from API in sourceNodes
2. create remote file nodes from the article_images_source array here
3. create article node and reference image file nodes with their respective id
4. use the @link directive in createSchemaCustomization to link images to article nodes

(truncated code example)

exports.sourceNodes = async ({
  actions: { createNode, createNodeField },
  createContentDigest,
  createNodeId,
  getCache,
}) => {

  let allArticles = []
  try {
    allArticles = await fetch("{article_source_url}")
    allArticles = await allArticles.json()
  } catch (error) {
    console.warn("ERROR creating Articles from API", error)
  } 

  const promisedArticles = allArticles.map(async (article) => {

    const article_node_id = createNodeId(article.article_id)

    const promisedArticleImages = article.article_images_source?.map(
      async ({ image_url }) => {
        let articleImageNode
        try {
          articleImageNode = await createRemoteFileNode({
            url: image_url,
            parentNodeId: article_node_id,
            getCache,
            createNode,
            createNodeId,
          })
        } catch (error) {
          console.log(error)
        }
        return articleImageNode
      }
    )

    const all_article_image_nodes = !!article.article_images_source
      ? await Promise.all(promisedArticleImages)
      : []

    let thumbnailImageNode

    try {
      thumbnailImageNode = await createRemoteFileNode({
        url: article.thumbnail_url,
        parentNodeId: article_node_id,
        createNodeId,
        createNode,
        getCache,
      })
    } catch (error) {
      console.log(error)
    }

    const articleNode = await createNode({
      article_images_source: article.article_images_source,
      article_images: all_article_image_nodes?.map(({ id }) => id),
      thumbnail: thumbnailImageNode?.id,
      thumbnail_url: article.thumbnail_url,
      // {... lots of other data}
      // required fields
      id: article_node_id,
      parent: null,
      children: [],
      internal: {
        type: `Article`,
        contentDigest: createContentDigest(article),
      },
    })
    return articleNode
  })
  await Promise.all(promisedArticles)
}

[...]

exports.createSchemaCustomization = ({ actions, schema }) => {
  const { createTypes } = actions

  const typeDefs = [ 
   ` 

   type ArticleImagesSource {
       // ... other
       image_url: String,
    }

   type Article implements Node {
      article_images: [File] @link,
      thumbnail: File @link,
      article_images_source: [ArticleImagesSource],
      // {... some other data}
    }
   `
  ]
 createTypes(typeDefs)
}

This works, but only if you build w/out the build-cache, meaning the first time you run gatsby build && gatsby serve or gatsby develop the page builds just fine and all the images are there. If then however you rebuild the site without clearing the cache (which happens a lot in our project, all images from article-pages are gone and if you reproduce the error locally in dev-mode, you can see in the GrapgQL web-UI that the article<->image_node links seem to break when you rebuild the site.
However, this only affects the article_images, not the thumbnail as they work in consecutive builds just fine.

I found a working solution tho:

(short description)

1. create article nodes with sourceNodes
2. use onCreateNode to create image nodes from the array in said article node
3. use schema.buildObjectType to link article images to article node

(truncated code example)

exports.sourceNodes = async ({
  actions: { createNode, createNodeField },
  createContentDigest,
  createNodeId,
  getCache,
}) => {
   // [...]
    const articleNode = await createNode({
      article_images_source: article.article_images_source,
      // {... lots of other data}
      // required fields
      id: article_node_id,
      parent: null,
      children: [],
      internal: {
        type: `Article`,
        contentDigest: createContentDigest(article),
      },
    })
   // [...]
}

// [...]

exports.onCreateNode = async ({
  node,
  actions: { createNode, createNodeField, deleteNode },
  cache,
  getCache,
  createNodeId,
  createContentDigest,
}) => {
  if (node.internal.type !== "Article") {
    return
  }

  const promisedArticleImages = node.article_images_source.map(
    async ({ image_url }) => {

      let articleImageNode
      try {
        articleImageNode = await createRemoteFileNode({
          url: image_url,
          parentNodeId: node.id,
          createNode,
          createNodeId,
          getCache,
          name: `articleImage`,
        })
      } catch (error) {
        console.log(error)
      }
      return articleImageNode
    }
  )
  await Promise.all(promisedArticleImages)
}

// [...]

exports.createSchemaCustomization = ({ actions, schema }) => {
  const { createTypes } = actions

  const typeDefs = [ 
   ` 
   type ArticleImagesSource {
       // ... other
       image_url: String,
    }

   type Article implements Node {
      article_images_source: [ArticleImagesSource],
      thumbnail: File @link,
      article_images_source: [ArticleImagesSource],
      // {... some other data}
    }
   `
    schema.buildObjectType({
      name: "Article",
      fields: {
        article_images: {
          type: ["File"],
          resolve: async (source, args, context, info) => {
            const { entries } = await context.nodeModel.findAll({
              query: {
                filter: {
                  // The name here is mainly used, because we have some more images associated with each article. 
                  // They have the same problem and work the exact same way as the "article_images"
                  name: { eq: "articleImage" },
                  parent: { id: { eq: source.id } },
                },
              },
              type: "File",
            })
            return entries
          },
        },     
      },
      interfaces: ["Node"],
    }),
]
 createTypes(typeDefs)
}

Does anybody have a clue, why the first example results in missing images and the second one works reliably?

[graysonhicks]

Hi @f-kottek ! Thanks for the great details and description. I think the best place for this would be a new issue with a reproduction.

[ariadne-github]

nodeModel.runQuery

• Description of the change This method is available in custom resolvers and returns an unbound array of nodes (without limit/skip applied). This is cheap with in-memory data but expensive when using DBs. Successor methods nodeModel.findOne and nodeModel.findAll support limit and skip directly. We already removed usages of this method in our own code (see this PR) but plugins are likely still using it.
• Why did we change this? It is expensive and wasteful in the world of DBs
• Who might this impact? Source plugins, sites using custom resolvers and schema customization

I'm not sure there's good replacement for this method. On the contrary, more of this is needed, and with a more friendly developer experience.

What's the recommended way to handle a large website with different data sources that have to be stitched together (which should be one of the common use cases of Gatsby)? Since now, I've been using createSchemaCustomization with custom resolvers everywhere, to have on some nodes custom properties that come from the same origin or another and are queried using nodeModel.runQuery and then maybe processed further. In a nutshell, I'm using the resolvers to implement all the business logic that is needed to connect different data sources or to precompute data so that is ready for the templates. I think that is the most efficient method since it only runs at build time (as opposed to write that logic inside react templates). It also aligns well with the philosophy of a static site generator to precompute at build time everything that can be done upfront. The developer experience is a little poor because the server has to be restarted for changes in resolvers to be reflected.

This change makes me think that somehow you don't think this is the right direction. If it's so, how do you recommend to handle use cases like this one?

[vladar]

findAll and findOne are basically a drop-in replacement for runQuery. This is equivalent:

nodeModel.runQuery({ type: `MyType`, query: { /* ... */ }, firstOnly: false })
// is the same as:
nodeModel.findAll({ type: `MyType`, query: { /* ... */ } })

nodeModel.runQuery({ type: `MyType`, query: { /* ... */ }, firstOnly: true })
// is the same as:
nodeModel.findOne({ type: `MyType`, query: { /* ... */ } })

The difference is only in how they handle limit/skip arguments. runQuery ignores them when passed. It will return all results that match the query - even if there are thousands of them. So here is the only difference:

// Assuming we have 100,000 nodes of the type `MyQuery`, the following returns all 100,000 nodes
nodeModel.runQuery({ type: `MyType`, query: { limit: 20, skip: 10 }, firstOnly: false }) 

// findAll returns 20 nodes (starting from 10th)
nodeModel.findAll({ type: `MyType`, query: { limit: 20, skip: 10 } })

If you don't pass limit and skip to findAll it behaves the same way as runQuery. But keep in mind that it will be inefficient for big datasets. Gatsby slowly introduces persisted data store (using lmdb-store) and fetching an unbounded number of nodes won't play well with it in the long run.

[ariadne-github]

Thanks @vladar, I didn'd find the documentation for the new mehtods, and the name was a little misleading. If they provide the same query capability, with the actually functioning limit and skip options, that's perfect. As I'm relying on the query, I'm always filtering the dataset, so I'd never end up with a large number of nodes in return.

[LekoArts]

We have a more detailed version here now: https://v4.gatsbyjs.com/docs/reference/release-notes/migrating-from-v3-to-v4/#nodemodelrunquery-is-deprecated

[cameronbraid]

Creating nodes in resolvers is also a very developer friendly solution, for example I have HTML in various fields coming from a custom CMS that I wish to convert to MDX. I just write a resolver @webappMdx and can use it like this :

    type WebappMdx implements Node {
      id: ID!
      childMdx: Mdx
    }
    type WebappPromotion implements Node {
      description: String
      descriptionMdx: WebappMdx @webappMdx(from:"description")
    }
    type WebappSupplierPage implements Node {
      extraContentHtml: String
      extraContentMdx: WebappMdx @webappMdx(from:"extraContentHtml")
    }
    type WebappLocationLandingPage implements Node {
      introImageUrl: String
      introImage: File @webappRemoteFile(from:"introImageUrl")
      articles: [WebappLocationLandingPageArticle!]!
      itinerariesMdx: WebappMdx @webappMdx(from:"itinerariesHtml")
      extraContentMdx: WebappMdx @webappMdx(from:"extraContentHtml")
      localPaths: [String!]! @webappLocalPaths
    }

I should stress that the lazy aspect of this approach is very important as well, as the html to mdx conversion can be time consuming (as custom html pre-processors are also involved). It is often the case that not all the resolves need to be evaluated.

[cameronbraid]

I guess one option for keeping this developer experience, but sacrificing the lazy aspect, would be to iterate the node graph and 'call' the resolvers ahead of time.

[wardpeet]

Thanks for the comment. We'll be experimenting with the above approach more. The problem in Gatsby now is that transformers create Nodes and nodes become part of the nodeStore. These directives could just return data without creating a real node.

[mrudden]

Still working through how to solve this one, but I'm having issues with gatsby develop after updating my local environment to Gatsby 4. They appear to be webpack related. I'll share anything I find here once I dive into this a bit more.

Here's what happens when I run gatsby develop:

❯ gatsby develop
success open and validate gatsby-configs, load plugins - 4.383s
success onPreInit - 0.022s
success initialize cache - 0.149s
success copy gatsby files - 0.446s
success Compiling Gatsby Functions - 1.195s
success onPreBootstrap - 1.260s
success createSchemaCustomization - 0.059s
success Checking for changed pages - 0.003s
success source and transform nodes - 0.823s
success building schema - 1.779s
success createPages - 0.004s
success createPagesStatefully - 0.716s
info Total nodes: 97, SitePage nodes: 12 (use --verbose for breakdown)
success Checking for changed pages - 0.005s
success write out redirect data - 0.007s
success onPostBootstrap - 0.016s
info bootstrap finished - 17.094s
success onPreExtractQueries - 0.005s
success extract queries from components - 4.732s
success write out requires - 0.058s
success run page queries - 0.042s - 1/1 23.92/s

 ERROR 

The 'compilation' argument must be an instance of Compilation



  TypeError: The 'compilation' argument must be an instance of Compilation
  
  - NormalModule.js:203 Function.getCompilationHooks
    [my_username]/[webpack]/lib/NormalModule.js:203:10
  
  - index.js:253 
    [example.com]/[@pmmmwh]/react-refresh-webpack-plugin/lib/index.js:253:26
  
  
  - Hook.js:14 Hook.CALL_DELEGATE [as _call]
    [example.com]/[gatsby]/[tapable]/lib/Hook.js:14:14
  
  - Compiler.js:1053 Compiler.newCompilation
    [example.com]/[gatsby]/[webpack]/lib/Compiler.js:1053:26
  
  - Compiler.js:1097 
    [example.com]/[gatsby]/[webpack]/lib/Compiler.js:1097:29
  
  
  - Hook.js:18 Hook.CALL_ASYNC_DELEGATE [as _callAsync]
    [example.com]/[gatsby]/[tapable]/lib/Hook.js:18:14
  
  - Compiler.js:1092 Compiler.compile
    [example.com]/[gatsby]/[webpack]/lib/Compiler.js:1092:28
  
  - Watching.js:200 
    [example.com]/[gatsby]/[webpack]/lib/Watching.js:200:19
  
  
  - runMicrotasks
  
  - task_queues.js:95 processTicksAndRejections
    internal/process/task_queues.js:95:5
  

not finished Building development bundle - 8.817s

Here's some info about what I did to prepare after following the migration guide:

❯ node -v
v14.18.0
❯ history
  463  npm outdated
  465  npm install gatsby@latest
  466  npm i -g gatsby-cli
  468  npm install gatsby-plugin-image@latest
  469  npm install gatsby-plugin-mdx@latest
  470  npm install gatsby-plugin-netlify-cms@latest
  471  npm install gatsby-plugin-sharp@latest
  472  npm install gatsby-remark-images@latest
  473  npm install gatsby-source-filesystem@latest
  474  npm install gatsby-transformer-sharp@latest
  475  npm build
  477  npm install gatsby-plugin-postcss@latest
  479  gatsby build
  480  gatsby develop
  481  npm update
  482  node -v

Additionally, here is an excerpt from my package.json file:

  "dependencies": {
    "@mdx-js/mdx": "^1.6.22",
    "@mdx-js/react": "^1.6.22",
    "gatsby": "^4.0.0",
    "gatsby-plugin-image": "^2.0.0",
    "gatsby-plugin-mdx": "^3.0.0",
    "gatsby-plugin-netlify-cms": "^6.0.0",
    "gatsby-plugin-sharp": "^4.0.0",
    "gatsby-remark-images": "^6.0.0",
    "gatsby-source-filesystem": "^4.0.0",
    "gatsby-transformer-sharp": "^4.0.0",
    "netlify-cms-app": "^2.15.54",
    "react": "^17.0.1",
    "react-dom": "^17.0.1"
  },
  "devDependencies": {
    "autoprefixer": "^10.3.7",
    "gatsby-plugin-postcss": "^5.0.0",
    "postcss": "^8.3.11",
    "tailwindcss": "^2.2.17"
  }
}

[wardpeet]

Can you try running npm dedupe and if that not works, remove package-lock.json. Seems like you have 2 versions of webpack installed

[mrudden]

@wardpeet Thanks for the tips! npm dedupe didn't work because of an error in a package name, but renaming package-lock.json and running npm install cleared everything up. I appreciate you reaching out when you did!

[brandshore]

I'm glad to experiment with Gatsby 4 from now! It's DSG functionality seems to be awesome.

I'm not sure if this is the the right thread to ask this, but after deploying the new Gatsby 4 starter on Gatsby Cloud the SSR and DSG pages showing 2 and 4 while I only have 1 ssr page and 2 dsg... Not sure why it doubles even though I turned off preview deploy (so it was not related).

[LekoArts]

This is a bug on the Cloud site that we're tracking!

[pedrolamas]

I'm currently having issues in Gatsby 4 with my gatsby-remark-acronyms plugin that I never experienced before!

From what I can tell, the initial plugin validation is failing because my plugin entry point is under a "dist" folder instead of the root of the plugin (mind you, there is a "main" entry pointing on the plugin package.json, pointing to this file), but this works fine in Gatsby 2 and 3.

Repro is quite easy, I just created a new Gatsby site with gatsby new, only specification I added was to have markdown with MDX, and then run npm add gatsby-remark-acronyms.

On the gatsby-config.js I replaced this:

`gatsby-plugin-mdx`,

with this:

{
  resolve: `gatsby-plugin-mdx`,
  options: {
    gatsbyRemarkPlugins: [
      {
        resolve: `gatsby-remark-acronyms`,
        options: {
          acronyms: {
            API: 'Application Programming Interface',
            ASAP: 'As Soon As Possible'
          },
        },
      },
    ],
  },
},

When I run npm run build, this is what I got:

> [email protected] build D:\Projects\gatsby-test
> gatsby build

Error: Cannot find module 'D:/Projects/gatsby-test/node_modules/gatsby-remark-acronyms/index'
Require stack:
- D:\Projects\gatsby-test\node_modules\gatsby\dist\bootstrap\load-plugins\validate.js
- D:\Projects\gatsby-test\node_modules\gatsby\dist\bootstrap\load-plugins\load.js
- D:\Projects\gatsby-test\node_modules\gatsby\dist\bootstrap\load-plugins\index.js
- D:\Projects\gatsby-test\node_modules\gatsby\dist\bootstrap\load-config-and-plugins.js
- D:\Projects\gatsby-test\node_modules\gatsby\dist\services\initialize.js
- D:\Projects\gatsby-test\node_modules\gatsby\dist\services\index.js
- D:\Projects\gatsby-test\node_modules\gatsby\dist\bootstrap\index.js
- D:\Projects\gatsby-test\node_modules\gatsby\dist\commands\build.js
- D:\Projects\gatsby-test\node_modules\gatsby-cli\lib\create-cli.js
- D:\Projects\gatsby-test\node_modules\gatsby-cli\lib\index.js
- D:\Projects\gatsby-test\node_modules\gatsby\dist\bin\gatsby.js
- D:\Projects\gatsby-test\node_modules\gatsby\cli.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:889:15)
    at Function.resolve (D:\Projects\gatsby-test\node_modules\v8-compile-cache\v8-compile-cache.js:164:23)
    at D:\Projects\gatsby-test\node_modules\gatsby\src\bootstrap\load-plugins\validate.ts:234:52
    at Object.validate (D:\Projects\gatsby-test\node_modules\joi\lib\types\any.js:47:28)
    at Object.internals.rules (D:\Projects\gatsby-test\node_modules\joi\lib\validator.js:394:33)
    at Object.exports.validate (D:\Projects\gatsby-test\node_modules\joi\lib\validator.js:350:22)
    at internals.Base.$_validate (D:\Projects\gatsby-test\node_modules\joi\lib\base.js:773:26)
    at Object.validate (D:\Projects\gatsby-test\node_modules\joi\lib\types\array.js:273:45)
    at Object.internals.rules (D:\Projects\gatsby-test\node_modules\joi\lib\validator.js:394:33)
    at Object.exports.validate (D:\Projects\gatsby-test\node_modules\joi\lib\validator.js:350:22)
    at internals.Base.$_validate (D:\Projects\gatsby-test\node_modules\joi\lib\base.js:773:26)
    at Object.validate (D:\Projects\gatsby-test\node_modules\joi\lib\types\keys.js:108:45)
    at Object.exports.validate (D:\Projects\gatsby-test\node_modules\joi\lib\validator.js:325:26)
    at Object.internals.entry (D:\Projects\gatsby-test\node_modules\joi\lib\validator.js:142:28)
    at Object.exports.entryAsync (D:\Projects\gatsby-test\node_modules\joi\lib\validator.js:58:30)
    at internals.Base.validateAsync (D:\Projects\gatsby-test\node_modules\joi\lib\base.js:553:26) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby\\dist\\bootstrap\\load-plugins\\validate.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby\\dist\\bootstrap\\load-plugins\\load.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby\\dist\\bootstrap\\load-plugins\\index.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby\\dist\\bootstrap\\load-config-and-plugins.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby\\dist\\services\\initialize.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby\\dist\\services\\index.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby\\dist\\bootstrap\\index.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby\\dist\\commands\\build.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby-cli\\lib\\create-cli.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby-cli\\lib\\index.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby\\dist\\bin\\gatsby.js',
    'D:\\Projects\\gatsby-test\\node_modules\\gatsby\\cli.js'
  ]
}
success open and validate gatsby-configs, load plugins - 0.852s
success onPreInit - 0.004s
success initialize cache - 0.080s
success copy gatsby files - 0.096s
success Compiling Gatsby Functions - 0.284s
success onPreBootstrap - 0.297s

 ERROR #11321  PLUGIN

"gatsby-plugin-mdx" threw an error while running the createSchemaCustomization lifecycle:

Cannot read property 'setParserPlugins' of undefined



  TypeError: Cannot read property 'setParserPlugins' of undefined

  - create-schema-customization.js:79 Object.createSchemaCustomization
    [gatsby-test]/[gatsby-plugin-mdx]/gatsby/create-schema-customization.js:79:37

  - api-runner-node.js:430 runAPI
    [gatsby-test]/[gatsby]/src/utils/api-runner-node.js:430:22

  - api-runner-node.js:581 Promise.catch.decorateEvent.pluginName
    [gatsby-test]/[gatsby]/src/utils/api-runner-node.js:581:13

  - debuggability.js:384 Promise._execute
    [gatsby-test]/[bluebird]/js/release/debuggability.js:384:9

  - promise.js:518 Promise._resolveFromExecutor
    [gatsby-test]/[bluebird]/js/release/promise.js:518:18

  - promise.js:103 new Promise
    [gatsby-test]/[bluebird]/js/release/promise.js:103:10

  - api-runner-node.js:579
    [gatsby-test]/[gatsby]/src/utils/api-runner-node.js:579:16

  - util.js:16 tryCatcher
    [gatsby-test]/[bluebird]/js/release/util.js:16:23

  - reduce.js:166 Object.gotValue
    [gatsby-test]/[bluebird]/js/release/reduce.js:166:18

  - reduce.js:155 Object.gotAccum
    [gatsby-test]/[bluebird]/js/release/reduce.js:155:25

  - util.js:16 Object.tryCatcher
    [gatsby-test]/[bluebird]/js/release/util.js:16:23

  - promise.js:547 Promise._settlePromiseFromHandler
    [gatsby-test]/[bluebird]/js/release/promise.js:547:31

  - promise.js:604 Promise._settlePromise
    [gatsby-test]/[bluebird]/js/release/promise.js:604:18

  - promise.js:649 Promise._settlePromise0
    [gatsby-test]/[bluebird]/js/release/promise.js:649:10

  - promise.js:729 Promise._settlePromises
    [gatsby-test]/[bluebird]/js/release/promise.js:729:18

  - async.js:93 _drainQueueStep
    [gatsby-test]/[bluebird]/js/release/async.js:93:12


not finished createSchemaCustomization - 0.116s

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `gatsby build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\pedro\AppData\Roaming\npm-cache\_logs\2021-10-26T10_00_52_634Z-debug.log

The error makes sense, as there is no "gatsby-remark-acronyms/index", but I would expect it to respect the "main" entry and thus use "gatsby-remark-acronyms/dist/index".

Is this expected behavior or some kind of bug introduced in Gatsby 4?

[pieh]

That's a bug. I created tracking issue for it in #33677

Thanks for report!

[pedrolamas]

Thank you for confirming, I will monitor the bug then!

[openscript]

In Gatsby V4 the PageContext is just a JSON field and the types are not inferenced anymore. As they state in their migration guide:

The built-in type SitePage now returns the pageContext key as JSON and won’t infer any other information anymore. The SitePlugin type now has two new keys: pluginOptions: JSON and packageJson: JSON.

With that, I also lose the typing which were generated from the GraphQL schema. How would you work around this to get back a typed PageContext to most easy way?

[ivanteso]

I believe I have a similar problem. Could you manage to get the old context field? Or it has been completely replaced by the new pageContext one (with no subfields/types) also in your case?

[ivanteso]

Hello, I'm currently having some trouble getting the context using the allSitePage query in graphQL.

{
  allSitePage {
    nodes {
      context {
        noIndex
      }
    }
  }
}

It has always been available until Gatsby 3 but now it looks like it's gone. As far as I can see, the context contains a mix of stuff injected from different templates using createPage, so it contains everything injected in the page context.

However, it looks like the context query is not available anymore in Gatsby 4, and somehow it has been replaced by pageContext.

{
  allSitePage {
    nodes {
      pageContext
    }
  }
}

This field contains more or less the same context stuff, but it's not possible to query its subfields, like noIndex (in my case), which is not ideal. However, the query result is JSON, and it's possible to select its content on a component level.

I couldn't find anything specific about the context query for this release, can someone clarify if this is expected behavior? And if yes, how can I get a very specific field within pageContext JSON on a query level?

[openscript]

@vladar Is there an easy way to bring back automatic inferencing?

[ivanteso]

Thank you all for your replies. Now everything is a bit more clear! :)

My use case is similar to the @openscript one but much simpler. Basically, we have a noIndex boolean that we inject in the page context. It might come from the CMS or toggle on createPage for some specific use case. Until now, we were using that boolean to exclude the pages with noIndex set to true from the sitemap.

We were using the allSitePage query on a page level to build the sitemap page and within the gatsby-plugin-sitemap. I guess the workaround provided by @vladar will do the job, I'll keep you posted! :D

[vladar]

Is there an easy way to bring back automatic inferencing?

Sadly no, because GraphQL schema is now prepared and frozen before we call createPages. If you really want inference - you can potentially create custom nodes for your pages in sourceNodes and use those nodes in queries and also as a source for page.context in createPages.

@openscript But can you share more details on the actual usage scenario - do you use it for navigation, sitemap generation, or something else?

[openscript]

@vladar We manipulate onCreatePage within different plugins to add information about the page context. For example:

• The pages locale
• The pages translations (alternative path and locale within an array)
• Other meta information

So in the page template we can render the page without additional queries.

[openscript]

We have added to all plugins a createSchemaCustomization. This seems to be a good replacement and we don't need automatic inferencing anymore :)

[LarsEjaas]

What is the recommended approach to debugging failing builds after upgrading to V4?
I have upgraded all plugins and dependencies to the latest version and reinstalled all Node_modules.

If I do a Gatsby clean and Gatsby build my build fails.

The build is failing when generating static HTML for pages.

I get this error:

 ERROR 

Page data from page-data.json for the failed page "/offline-plugin-app-shell-fallback/": {      
  "componentChunkName": "component---cache-caches-gatsby-plugin-offline-app-shell-js",
  "path": "/offline-plugin-app-shell-fallback/",
  "result": {
    "pageContext": {
      "language": "da",
      "i18n": {
        "language": "da",
        "languages": [
          "en",
          "da"
        ],
        "defaultLanguage": "da",
        "generateDefaultLanguagePage": false,
        "routed": false,
        "originalPath": "/offline-plugin-app-shell-fallback/",
        "path": "/offline-plugin-app-shell-fallback/"
      }
    }
  },
  "staticQueryHashes": [
    "1672338075",
    "2249152690"
  ]
}

[graysonhicks]

Hi @LarsEjaas I typically then run the site in develop and navigate to the offending page to look for warnings/errors in the terminal or browser console, as those are likely culprits.

[KyleAMathews]

Generally there should be a JS build error below the page data

[LarsEjaas]

@graysonhicks and @KyleAMathews Sorry for not responding earlier. I somehow missed your helpful replies. I actually just waited for the issue to be fixed in one of the minor Gatsby upgrades. It turned out to be a minor incompatibility with the Preact plugin. It was fixed and I could then upgrade with no issues 😃

[Boytobeaman]

As a developer, it is excited to see new versions published, I build a website selling moving crates using gatsby version 1 (website: https://www.movingboxsale.com) a few years ago,
and i wonder should I update the code to the latest version?

and I also have a website about wholesale supplier using nextjs and traditional wordpress website about plastic crates
Will there be a winner one for nextjs or gatsbyjs in the next 5 years? which one will you choose?

[tujoworker]

@Boytobeaman I hope we all can agree that the best thing is; there’s no winner. It should not be a battle at all.

They should only inspire each other – not compete. They should learn from each other – not fight. They should motivate developers to care about the code they write to create good and accessible UX.

Now, that’s at least my dream. Others would say, completion is good and drives innovation. But again, innovation should not be about to crown a winner.

Now, from what I can tell from my experience is that Gatsby cares about the DX really really well. I mean, if you upgrade from v1 to v4 – there is not too much that will break your code. This is something we devs have to applaud Gatsby very much; the APIs they write are well thought and do not need to change every 6 months.

[aliceHendicott]

Hello, I'm currently encountering a problem using a community plugin gatsby-remark-table-of-contents with gatsby-plugin-mdx after upgrading to v4.

The community plugin uses export default rather than module.exports to export its main function which has been fine up until this upgrade. Since the upgrade, the filter on gatsbyRemarkPlugins in gatsby-plugin-mdx here now determines the default export is an object rather then a function (it definitely is a function - see code here) and hence filters it out and doesn't run the transform (no errors or anything).

As soon as I change the export to be module.exports, the plugin works as expected.

I did some digging and found a change to gatsby-plugin-mdx which I believe to be the cause of this issue. In the upgrade, the filter for gatsbyRemarkPlugins in this commit was changed from:

const userPluginsFiltered = gatsbyRemarkPlugins.filter(
  plugin => typeof interopDefault(require(plugin.resolve)) === `function`
)

to

const userPluginsFiltered = gatsbyRemarkPlugins.filter(
  plugin => typeof plugin.module === `function`
)

Is this an intentional change or a bug?

[graysonhicks]

That change may be because of mdx-js move to ESM.

[Assitan]

Hello,

I've been trying to migrate to v4, currently in 3.8.0, but I have this error :

with a blank page when I do a npm run develop.

Any ideas?

Thanks.

[wasabigeek]

Hi! I seem to have a problem with "local" images being parsed in gatsby-transformer-remark between v3 and v4.

Fully-qualified web URLs such as ![KWAC Index](https://upload.wikimedia.org/wikipedia/commons/6/61/KWAC.png) are parsed correctly, but relative, "local" images in my /content folder e.g. ![Criteria for Decomposing Modules 2.png](./Criteria for Decomposing Modules 2.png) become part of the text.

I placed a breakpoint in /node_modules/gatsby-remark-images/index.js (around here) to check the markdownAST between the two versions, results below.

Results

This is the part of the AST with a relative image in [email protected], the image is correctly parsed:

The same block of content with a relative image in [email protected] (I'm showing v5 here, but confirmed that v4 is the same as well), the image is still part of the text:

In case it's helpful, I've a commit for the downgrade which worked.

[wasabigeek]

Ok, by accident I've found that the spaces in the image filename is tripping up remark. Images are correctly parsed if there are no spaces.

[alxndr]

I'm trying to update a project from 3.14.6 to v4, I am getting GraphQL errors related to the types I've defined to handle CSV data.

(Warning: I'm not really using GraphQL "correctly" in this project because I'm mid-migration from reading flat files into arrays-of-objects, and still using much of the existing selecting/sorting logic. I'll gladly accept any pointers on doing things The Right Way!)

I'm using gatsby-transformer-csv which I think uses gatsby-transformer-json, and I see in the v3-to-v4 migration guide that gatsby-transformer-json has a breaking change related to how it handles data with an id field.

The doc for gatsby-transformer-csv doesn't currently mention handling the id field specially, should it?

I've updated my queries which were previously filtering for and/or selecting the id field, but I am seeing errors about ERROR #85923 ... Cannot query field "SongsCsv" on type "Query" and various other "field" values (which I would expect to be the "type"). My latest attempt to upgrade and use this 'new API' can be seen in the spike/gatsby-v4-take4 branch.

⟫ gatsby develop --verbose
verbose set gatsby_log_level: "verbose"
verbose set gatsby_executing_command: "develop"
verbose loading local command from:
/Users/alxndr/workspace/almost-dead-net/node_modules/gatsby/dist/commands/develop.js
verbose running command: develop

verbose Transition to "initializing"
success compile gatsby files - 0.965s
success load gatsby config - 0.048s
success load plugins - 8.372s
success onPreInit - 0.012s
success initialize cache - 0.935s
success copy gatsby files - 1.241s
verbose Attaching functions to development server
success Compiling Gatsby Functions - 1.999s
success onPreBootstrap - 2.075s
verbose Creating 3 worker
verbose Transition to "initializingData"
success createSchemaCustomization - 0.063s
verbose Transition to "initializingData" > "sourcingNodes"
verbose Checking for deleted pages
verbose Deleted 0 pages
verbose Found 0 changed pages
success Checking for changed pages - 0.004s
success source and transform nodes - 8.869s
verbose Transition to "initializingData" > "buildingSchema"
success building schema - 0.687s
verbose Transition to "initializingData" > "creatingPages"
[Object: null prototype] { date: null, jsonId: null, venue: null }
[Object: null prototype] { jsonId: null, title: null }
[Object: null prototype] { jsonId: null, name: null }
venues missing name...........
{
  data: [Object: null prototype] {
    allVenuesCsv: [Object: null prototype] { nodes: [Array] },
    allSongsCsv: [Object: null prototype] { nodes: [Array] },
    allShowsCsv: [Object: null prototype] { nodes: [Array] }
  }
}
success createPages - 0.050s
success createPagesStatefully - 0.093s
info Total nodes: 4133, SitePage nodes: 9 (use --verbose for breakdown)
verbose Number of node types: 15. Nodes per type: Directory: 2, File: 11, GuestsCsv: 39,
RecordingsCsv: 582, SeguesCsv: 2542, SetsCsv: 674, ShowsCsv: 249, Site: 1, SiteBuildMetadata: 1,
SitePage: 9, SitePlugin: 34, SongperformancesCsv: 3931, SongsCsv: 459, TeasesCsv: 1054, VenuesCsv: 109
verbose Checking for deleted pages
verbose Deleted 0 pages
verbose Found 9 changed pages
success Checking for changed pages - 0.002s
verbose Transition to "initializingData" > "writingOutRedirects"
success write out redirect data - 0.003s
verbose Transition to "initializingData" > "done"
verbose Transition to "runningPostBootstrap"
success onPostBootstrap - 0.002s
info bootstrap finished - 69.823s
verbose Transition to "runningQueries"
success onPreExtractQueries - 0.002s

 ERROR #85923  GRAPHQL

There was an error in your GraphQL query:

Cannot query field "ShowsCsv" on type "Query".

If you don't expect "ShowsCsv" to exist on the type "Query" it is most likely a typo.
However, if you expect "ShowsCsv" to exist there are a couple of solutions to common problems:

- If you added a new data source and/or changed something inside gatsby-node.js/gatsby-config.js,
please try a restart of your development server
- The field might be accessible in another subfield, please try your query in GraphiQL and use the
GraphiQL explorer to see which fields you can query and what shape they have
- You want to optionally use your field "ShowsCsv" and right now it is not used anywhere. Therefore
Gatsby can't infer the type and add it to the GraphQL schema. A quick fix is to add at least one entry
 with that field ("dummy content")

It is recommended to explicitly type your GraphQL schema if you want to use optional fields. This way
you don't have to add the mentioned "dummy content". Visit our docs to learn how you can define the
schema for "Query":
https://www.gatsbyjs.com/docs/reference/graphql-data-layer/schema-customization#creating-type-definiti
ons

File: src/templates/show.js:86:5


 ERROR #85923  GRAPHQL

There was an error in your GraphQL query:

Cannot query field "ShowsCsv" on type "Query".

If you don't expect "ShowsCsv" to exist on the type "Query" it is most likely a typo.
However, if you expect "ShowsCsv" to exist there are a couple of solutions to common problems:

- If you added a new data source and/or changed something inside gatsby-node.js/gatsby-config.js,
please try a restart of your development server
- The field might be accessible in another subfield, please try your query in GraphiQL and use the
GraphiQL explorer to see which fields you can query and what shape they have
- You want to optionally use your field "ShowsCsv" and right now it is not used anywhere. Therefore
Gatsby can't infer the type and add it to the GraphQL schema. A quick fix is to add at least one entry
 with that field ("dummy content")

It is recommended to explicitly type your GraphQL schema if you want to use optional fields. This way
you don't have to add the mentioned "dummy content". Visit our docs to learn how you can define the
schema for "Query":
https://www.gatsbyjs.com/docs/reference/graphql-data-layer/schema-customization#creating-type-definiti
ons

File: src/templates/show-embed.js:114:5


 ERROR #85923  GRAPHQL

There was an error in your GraphQL query:

Cannot query field "SongsCsv" on type "Query".

If you don't expect "SongsCsv" to exist on the type "Query" it is most likely a typo.
However, if you expect "SongsCsv" to exist there are a couple of solutions to common problems:

- If you added a new data source and/or changed something inside gatsby-node.js/gatsby-config.js,
please try a restart of your development server
- The field might be accessible in another subfield, please try your query in GraphiQL and use the
GraphiQL explorer to see which fields you can query and what shape they have
- You want to optionally use your field "SongsCsv" and right now it is not used anywhere. Therefore
Gatsby can't infer the type and add it to the GraphQL schema. A quick fix is to add at least one entry
 with that field ("dummy content")

It is recommended to explicitly type your GraphQL schema if you want to use optional fields. This way
you don't have to add the mentioned "dummy content". Visit our docs to learn how you can define the
schema for "Query":
https://www.gatsbyjs.com/docs/reference/graphql-data-layer/schema-customization#creating-type-definiti
ons

File: src/templates/song.js:55:5


 ERROR #85923  GRAPHQL

There was an error in your GraphQL query:

Cannot query field "VenuesCsv" on type "Query".

If you don't expect "VenuesCsv" to exist on the type "Query" it is most likely a typo.
However, if you expect "VenuesCsv" to exist there are a couple of solutions to common problems:

- If you added a new data source and/or changed something inside gatsby-node.js/gatsby-config.js,
please try a restart of your development server
- The field might be accessible in another subfield, please try your query in GraphiQL and use the
GraphiQL explorer to see which fields you can query and what shape they have
- You want to optionally use your field "VenuesCsv" and right now it is not used anywhere. Therefore
Gatsby can't infer the type and add it to the GraphQL schema. A quick fix is to add at least one entry
 with that field ("dummy content")

It is recommended to explicitly type your GraphQL schema if you want to use optional fields. This way
you don't have to add the mentioned "dummy content". Visit our docs to learn how you can define the
schema for "Query":
https://www.gatsbyjs.com/docs/reference/graphql-data-layer/schema-customization#creating-type-definiti
ons

File: src/templates/venue.js:35:5

failed extract queries from components - 5.126s
verbose Transition to "runningQueries" > "waitingPendingQueries"
verbose Transition to "runningQueries" > "writingRequires"
success write out requires - 0.008s
verbose Transition to "runningQueries" > "calculatingDirtyQueries"
verbose Transition to "runningQueries" > "runningStaticQueries"
success run static queries - 1.072s - 6/6 5.60/s
verbose Transition to "runningQueries" > "runningPageQueries"
success run page queries - 0.046s - 3/3 65.25/s
verbose Transition to "runningQueries" > "waitingForJobs"
verbose Transition to "runningQueries" > "done"
verbose Transition to "startingDevServers"

 ERROR

There was an error compiling the html.js component for the development server.
See our docs page on debugging HTML builds for help https://gatsby.dev/debug-html  Cannot find module
'/Users/alxndr/workspace/almost-dead-net/public/loadable-stats.json'


  1 | 'use strict';
  2 | var token = '%[a-f0-9]{2}';
> 3 | var singleMatcher = new RegExp(token, 'gi');
    | ^
  4 | var multiMatcher = new RegExp('(' + token + ')+', 'gi');
  5 |
  6 | function decodeComponents(components, split) {


  WebpackError: Cannot find module '/Users/alxndr/workspace/almost-dead-net/public/loadable-stats.json
  '

  - index.js:3
    [almost-dead-net]/[decode-uri-component]/index.js:3:1

  - utils.js:156
    [almost-dead-net]/[@gatsbyjs]/reach-router/lib/utils.js:156:1

  - index.js:75
    [almost-dead-net]/[decode-uri-component]/index.js:75:1

  - setPrototypeOf.js:4
    [almost-dead-net]/[@babel]/runtime/helpers/setPrototypeOf.js:4:1

  - util.js:43
    [almost-dead-net]/[@loadable]/server/lib/util.js:43:1

  - ChunkExtractor.js:204
    [almost-dead-net]/[@loadable]/server/lib/ChunkExtractor.js:204:1

  - gatsby-ssr.js:10
    almost-dead-net/gatsby-ssr.js:10:19

  - bootstrap:19
    almost-dead-net/webpack/bootstrap:19:1

  - api-runner-ssr.js:23
    almost-dead-net/.cache/api-runner-ssr.js:23:15

  - bootstrap:19
    almost-dead-net/webpack/bootstrap:19:1

  - about.js:15
    almost-dead-net/src/pages/about.js:15:152

  - bootstrap:19
    almost-dead-net/webpack/bootstrap:19:1

  - startup:4
    almost-dead-net/webpack/startup:4:1

  - index.js:38
    [almost-dead-net]/[gatsby-link]/index.js:38:1

  - index.js:223
    [almost-dead-net]/[gatsby-link]/index.js:223:1


not finished Building development bundle - 46.660s

[graysonhicks]

If you run the site in develop, are you able to query SongsCsv or VenuesCsv in GraphiQL?

[graysonhicks]

Also, I'm not sure that transformer-csv does use transformer-json.

[graysonhicks]

You'll also want to remove all your own loadable code from gatsby-ssr, gatsby-browser, and gatsby-node. The new loadable plugin you have should do all that for you and get you around the stats file error.

[graysonhicks]

I think the issue with the queries is that the type when it is queried singularly is is showsCsv etc (note the lowercase). Let me know if that resolves along with the loadable fix above, thanks!

[alxndr]

Thanks @graysonhicks ! I've changed my types to start with a lowercase letter, and removed the loadable-related code I could find, and changed jsonId back to id.

Now I seem to be getting errors from how I've been filtering in queries, eg.

export const query = graphql`
  query VenuePage($venueId: String!) {
    venuesCsv(id: {eq: $venueId}) {
      id
    }
    allShowsCsv(filter: {venue: {id: {eq: $venueId}}}) {
      nodes {
        id
      }
    }
  }
`

 ERROR #85901  GRAPHQL

There was an error in your GraphQL query:

Field "venue" is not defined by type "ShowsCsvFilterInput".

File: src/templates/venue.js:38:26



  GraphQLError: Field "venue" is not defined by type "ShowsCsvFilterInput".

  - query-compiler.js:209 extractOperations
    [almost-dead-net]/[gatsby]/src/query/query-compiler.js:209:20

  - query-compiler.js:167 processQueries
    [almost-dead-net]/[gatsby]/src/query/query-compiler.js:167:45

  - query-compiler.js:78 compile
    [almost-dead-net]/[gatsby]/src/query/query-compiler.js:78:19

  - query-watcher.ts:223 updateStateAndRunQueries
    [almost-dead-net]/[gatsby]/src/query/query-watcher.ts:223:40

  - extract-queries.ts:18 extractQueries
    [almost-dead-net]/[gatsby]/src/services/extract-queries.ts:18:3

The build seems to continue processing, and then fails with this:

 ERROR

Couldn't get query results for "/" in 15.000s.

[msestili]

Hi,

I have migrated a project I'm working on from v3 to v4 and the building time has increased drastically. success source and transform nodes - 5029.628s with v3 was 9.390s. It build successfully, it only take hours to do that.

I have tried to build with --verbose but it doesn't highlight any issues. I've been wondering if it could be due to some changes in the gatsby-transformer-json or gatsby-plugin-sharp

Can someone help on this matter? Below the packages I am using and their versions

        "gatsby": "^4.0.0",
        "gatsby-plugin-emotion": "^7.25.0",
        "gatsby-plugin-image": "^2.25.0",
        "gatsby-plugin-manifest": "^4.25.0",
        "gatsby-plugin-react-helmet": "^5.25.0",
        "gatsby-plugin-react-svg": "^3.3.0",
        "gatsby-plugin-runtime-path-prefix": "^2.0.1",
        "gatsby-plugin-sharp": "^4.25.1",
        "gatsby-plugin-sitemap": "^5.25.0",
        "gatsby-source-filesystem": "^4.25.0",
        "gatsby-transformer-json": "^4.25.0",
        "gatsby-transformer-sharp": "^4.25.0",