Add ability to locally define plugins

[0x80]

Additionally I cleaned up the test plugin logic to make it more readable.

[gatsbybot]

Deploy preview ready!

Built with commit 9b822cb

https://deploy-preview-1126--using-drupal.netlify.com

[gatsbybot]

Deploy preview ready!

Built with commit 9b822cb

https://deploy-preview-1126--gatsbygram.netlify.com

[gatsbybot]

Deploy preview ready!

Built with commit 9b822cb

https://deploy-preview-1126--gatsbyjs.netlify.com

[KyleAMathews]

Couple notes:

• Local plugins should be in a plugins directory
• Local plugins should override node_modules. So first try to resolve a plugin there and then failing that try node_modules. This would allow someone to copy an open source plugin locally to make modifications to how it works.

[0x80]

I agree on your second point, but can you explain why we need a fixed convention for a plugins folder?

Currently you give a relative path to the plugin in the config. I was placing mine in src/plugins for example because I still see it as part of my source. But I don't yet see a need to define this for the user.

[KyleAMathews]

Hmmm I guess I like the idea of just putting the plugin names in the config not intermixing paths and names which seems confusing.

I'm not 100% sure I like src/plugins as the way I've been thinking about src/ is it's for client/web code while outside of it e.g. the gatsby-* files are for code around building the site. To me plugins fall in that category not client code.

[0x80]

@KyleAMathews OK let's limit loading to plugins folder then. I see your points, and I don't think it can hurt really. It would make things a bit more concise and robust probably.

[0x80]

@KyleAMathews I've limited the plugins to the plugins folder.

A few things I'm not completely certain / happy about yet:

• Local plugins require a package.json file. But this seems a bit unnecessary / cumbersome. I could circumvent this requirement if you think it's useful.
• I'm wondering what happens to the cache when you tweak a local plugin during development (haven't tested yet). One of the reasons I'd really like local plugins is for doing quick iterations on plugin code. If it would be cached on say plugin version number, then this would be problematic.
• Throwing an error in load-plugins results in an UNHANDLED REJECTION. This rejection should probably be handled, or maybe I can avoid a throw and instead trigger a Redux action to signal an error, but I don't think those exist yet?

What do you think?

[KyleAMathews]

Local plugins require a package.json file. But this seems a bit unnecessary / cumbersome. I could circumvent this requirement if you think it's useful.

What Hapi.js does is their index.js returns the plugin name usually taken straight from the package.json but not necessarily. That's one possibility. Another could be using the folder name as the plugin name if a package.json doesn't exist. But in any case, let's just leave the package.json requirement for now and get this in and discuss changing plugin requirements later.

I'm wondering what happens to the cache when you tweak a local plugin during development (haven't tested yet). One of the reasons I'd really like local plugins is for doing quick iterations on plugin code. If it would be cached on say plugin version number, then this would be problematic

The default site gatsby-node.js has the same problem. For that, in bootstrap.js I added some code which generates the md5 hash of the gatsby-node.js and gatsby-config.js files and kills the cache when they change. We should do the same for other local plugins.

Throwing an error in load-plugins results in an UNHANDLED REJECTION. This rejection should probably be handled, or maybe I can avoid a throw and instead trigger a Redux action to signal an error, but I don't think those exist yet?

Yeah, we haven't added yet a pattern for capturing internal errors...

[0x80]

OK the way I solved it now is that package.json is required for local plugins, but it doesn't have to contain anything real.

If the package file has no name, it is inferred from the directory.
If the package file has no version, an md5 hash is created from the file contents.

I used the same md5 creation function on the "site" plugin instead of setting its version to "n/a". If I understand things correctly this would make the hashing in bootstrap redundant. Let me know if you want me to remove that.

While I was trying to use async functions I messed up the bootstrap a few times, leading to vague graphql errors or an empty pages store. I added some checks to give clearer error messages.

[KyleAMathews]

Looks like snapshots need updated.

[KyleAMathews]

Deploy preview failed.

Built with commit 89eafc7

https://app.netlify.com/sites/image-processing/deploys/593ef432424ef22861f6c4f0

[0x80]

@KyleAMathews I updated the snapshots, and fixed a load-plugins test I had broken.

I am seeing a lot of other tests failing about GraphQL like below, but I'm assuming those are unrelated. They also fail for me on the master. I switched back to Node 7 also because I couldn't get the tests to work with version 8.

 packages/gatsby/src/schema/__tests__/infer-graphql-input-type-test.js
  ● GraphQL Input args › filters out null example values

    RootQueryType.allNode field type must be Output Type but got: TestConnection.

[KyleAMathews]

RootQueryType.allNode field type must be Output Type but got: TestConnection.

This crops all the time and you kinda have to ignore it locally. It's kinda the same thing as the "two react" problem. GraphQL will get installed multiple times and then the identity checks it uses will fail because it's comparing an object from one install of GraphQL to a different install.

Either you can go hunting for the extra package and remove it, reinstall everything from scratch, or ignore it unless you're working on graphql related code and trust the test results from TravisCI.

As it is, tests are passing on TravisCI so it looks like we're good :-)

[KyleAMathews]

Could you also add a bit of documentation to https://www.gatsbyjs.org/docs/plugins/ as well real quick?

[0x80]

@KyleAMathews Sure, I'll write something...

[KyleAMathews]

Deploy preview failed.

Built with commit 9b822cb

https://app.netlify.com/sites/using-glamor/deploys/593f9df3424ef24d84f6c540

[KyleAMathews]

Looks awesome! Thanks so much for taking this on! Let's get babel support for local plugins as well soon.