fix: future-proof functionality through Gatsby schema customization

[wKovacs64]

What

Update the node augmentation logic to fall in line with the direction Gatsby is heading (i.e. remove direct node manipulation) to prevent immediate and future breakage.

Closes #28

How

Use Gatsby schema customization (createResolvers) to augment the user-supplied node type by adding a field with a user-supplied name where the resolver for said field returns a File node created by createRemoteFileNode (from gatsby-source-filesystem).

Notes

💥 This bumps the required Gatsby peer dependency to 2.2.0 or greater, as that is when the new schema customization APIs were introduced. Not a huge deal, as it has been out since March of 2019, but it is a breaking change and (IMHO) warrants a v2.0.0 release of this plugin.

💡 I didn't see a slick way to communicate between the onCreateNode API and the createResolvers API, so I introduced a module-level variable to track the relationship between the node to be augmented and the corresponding dynamically created (remote) File node. It felt a little weird, but it works. One alternative could be a "hidden" (undocumented) plugin option as both API methods get those passed in, but that felt ever stranger.

🔧 As the new File nodes are no longer being directly injected into the source/parent nodes, the previously existing tests were no longer able to verify the correct File node was present. In some cases, I adapted them to just ensure things were being called with the appropriate parameters and in other cases I simply removed the node verification assertion. It's not ideal and I suspect they can be improved, but it's better than nothing. A follow-up PR or suggestions to improve them would be great.

[wKovacs64]

cc @vladar

[graysonhicks]

@wKovacs64 This is great, and I agree would work best as a new major release since it will be using a new underlying Gatsby API that is not available in pre 2.2.0 Gatsby. I will do a version 1 release with the prettier changes in #29 then a 2.0 with these changes.

I'll try and get this pulled down and test it locally and have a look the module level variable.

@smurrayatwork might have some thoughts on the tests.

Lastly, will this help address using the plugin with gatsby-source-graphql as mentioned in #7 ? I recall seeing some similar solutions in a blog somewhere lately.

[wKovacs64]

@graysonhicks As it stands, this won't address the gatsby-source-graphql issue in #7. It could be adapted to do so (potentially) by moving the node creation into the resolver, but that probably means doing away with onCreateNode entirely. I suspect the imagePath array literal notation feature is going to make that much more obnoxious than it would be otherwise, but I'd need to give it some more thought.

P.S.
Probably no need to release a new 1.x if the prettier changes are the only difference as that's purely style and formatting. The end result won't be any different.

[graysonhicks]

This works for me locally when npm link'd to a test repo. Going to merge this in to develop and release w/ #29 for 2.0.0. 👍