Support for Gatsby 3 and 4.

[dopry]

The latest version expects gatsby 2.x it appears while Gatsby has moved on to 4.x. Support for Gatsby >2.x would be nice.

I see the following with a gatsby 4 install...

warn Plugin gatsby-source-wagtail is not compatible with your gatsby version 4.3.0 - It requires gatsby@^2.13.77
warn Plugin gatsby-source-wagtail is not compatible with your gatsby version 4.3.0 - It requires gatsby@^2.13.77

"gatsby-source-wagtail" threw an error while running the sourceNodes lifecycle:

Unexpected token < in JSON at position 0

  ServerParseError: Unexpected token < in JSON at position 0

  - JSON.parse

Missing onError handler for invocation 'building-schema', error was 'Error: Cannot create as TypeComposer the following value:       
  Date.'. Stacktrace was 'Error: Cannot create as TypeComposer the following value:
  Date.

[isolationism]

I agree this is a pretty big problem considering Gatsby 2 is now completely unsupported; it looks like the project has been abandoned.

I have working proof-of-concept using a very particular, pinned toolchain that builds, but is wildly out of date; even the latest Gatsby 2 releases don't work; only a particular limited range.

Is there any interest in a group shoring up support for Gatsby 4? The only alternative I can see for a production JAMstack application with Wagtail is to switch to Next.js using https://github.com/Frojd/Wagtail-Pipit.

[dopry]

We ended up implementing GraphQL on our Wagatil site and using https://www.gatsbyjs.com/plugins/gatsby-source-graphql/ to pull content into gatsby. This worked very well for us.

[isolationism]

Thank you so much for replying, it's greatly appreciated.

I encountered the same plugin myself and wondered how difficult it would be to have to implement the builder tasks with a low-level tool, only to realize it looks like this project already depends on it and a bunch else besides.

This package is problematic for a few reasons including the ticket above as well as not executing correctly inside an (nx) monorepo because of some nuance of how package dependencies are resolved.

If I may be so bold as to ask you to share a little more information about your solution?

Do you enjoy the same or similar functionality supporting build of a full site including linked pages w/ templates for page types, images etc., or some other approach?

Is there any chance any of that code is available for review, or if not, at least what the magnitude of effort I'm facing to implement something like what you have might be?

I ask of course for myself as well as any other future visitors that might be similarly stuck on what seems like unsupported software. Escape hatch plans to the well-supported gatsby-source-graphql library you mentioned would be most welcome, whatever else you're willing to share. Again, thank you. 🙇

[zerolab]

Hey both,

I am not sure how much Gatsby @NathHorrigan is using any more. And considering the last commit was well over a year ago, we could consider this... unmaintained.

Now, if you guys are actively using it and would like to take over this and help bring it up to date, I am sure we can arrange something in terms of maintainer rights.

[dopry]

@zerolab I'm interested in so far as I need to implement better gatsby 4 support. I don't have the bandwidth to take on any sort of lead or ongoing maintainership role. It looks like the best route to implement the client is to rebuild it on top of https://github.com/gatsbyjs/gatsby-graphql-toolkit.

I'm concerned the scope of the changes required will lead to a new plugin that has little in common with the original. It'll defintely be a new major version at a minimum.

Is it better to keep those changes in this namespace to provide continuity for the community, or would it be better to start a new plugin altogether to better highlight the scope of change and mitigate the support overhead when the major change hits the distribution channels?

[isolationism]

I have decided to abandon Gatsby myself in favour of Next.js, by way of Wagtail-Pipit as a boilerplate to get mine off the ground.

While the Pipit/Next.js route has required some substantial effort to recreate equivalent functionality to that provided by Gatsby and this plugin, the project is a better fit for my use case.

For the benefit of future readers: Unless you are locked into using Gatsby and/or using GraphQL, I recommend considering Next.js for rendering instead of Gatsby, and Pipit's DRF approach for serialization. The latter in particular is dramatically more sustainable in the long-term as Wagtail itself uses DRF for its own public API.