Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: improve documentation for plugin authors #4272

Merged
merged 12 commits into from
Mar 1, 2018
2 changes: 1 addition & 1 deletion CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ Looking to speak about Gatsby? We'd love to review your talk abstract/CFP! You c

### Creating your own plugins and loaders

If you create a loader or plugin, we would <3 for you to open source it, and put it on npm.
If you create a loader or plugin, we would <3 for you to open source it, and put it on npm. For more information on creating custom plugins, please see the documentation for [plugins](/docs/plugins/) and the [API specification](/docs/api-specification/).

### Contributing to the repo

Expand Down
65 changes: 65 additions & 0 deletions docs/docs/plugin-authoring.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
---
title: Plugin Authoring
---

One of the best ways to add functionality to Gatsby is through our plugin system. Gatsby is designed to be extensible, which means plugins are able to modify and extend just about everything Gatsby does.

Of the many possibilities, plugins can:

- add external data or content (e.g. your CMS, static files, a REST API) to your Gatsby GraphQL data
- transform data from other formats (e.g. YAML, CSV) to JSON objects
- add third-party services (e.g. Google Analytics, Instagram) to your site
- anything you can dream up!

## Core Concepts

- Each Gatsby plugin can be installed as an npm package or as a [local plugin](#local-plugins)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦‍♂️ Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Capitalize NPM

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Their official branding appears to keep it lowercase: https://www.npmjs.com/ 😕

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about "Each Gatsby plugin an be created as an NPM package or as a..."

It seems odd to say you're "installing" a local plugin which you'd rarely do.

- A `package.json` is required
- Plugin implement the Gatsby APIs for [Node](/docs/node-apis/), [server-side rendering](/docs/ssr-apis/), and the [browser](/docs/browser-apis/)

## Plugin naming conventions

There are four standard plugin naming conventions for Gatsby:

- **`gatsby-source-*`** — a source plugin loads data from a given source (e.g. WordPress, MongoDB, the file system). Use this plugin type if you are connecting a new source of data to Gatsby.
- Example: [`gatsby-source-contentful`](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-source-contentful)
- Docs: [create a source plugin](/docs/create-source-plugin/)
- **`gatsby-transformer-*`** — a transformer plugin converts data from one format (e.g. CSV, YAML) to a JavaScript object. Use this naming convention if your plugin will be transforming data from one format to another.
- Example: [`gatsby-transformer-yaml`](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-transformer-yaml)
- **`gatsby-[plugin-name]-*`** — if a plugin is a plugin for another plugin 😅, it should be prefixed with the name of the plugin it extends (e.g. if it adds emoji to the output of `gatsby-transformer-remark`, call it `gatsby-remark-add-emoji`). Use this naming convention whenever your plugin will be included as a plugin in the `options` object of another plugin.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing plugin creators will get this, and possibly I'm just the one who is confused. Because it sounds like if you just keep adding something to the end of all applicable prefixes, wouldn't it be gatsby-transformer-remark-add-emoji? I mean, that's insanely long, but these instructions would have made me think that was correct without the helpful example. Does that make sense?

- Example: [`gatsby-remark-images`](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-remark-images)
- **`gatsby-plugin-*`** — this is the most general plugin type. Use this naming convention if your plugin doesn’t meet the requirements of any other plugin types.
- Example: [`gatsby-plugin-sharp`](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin-sharp)

## What files does Gatsby look for in a plugin?

All files are optional unless specifically marked as required.

- `package.json` — [required] this can be an empty object (`{}`) for local plugins
- `name` is used to identify the plugin when it mutates Gatsby’s GraphQL data structure
- if `name` isn’t set, the folder name for the plugin is used
- `version` is used to manage the cache — if it changes, the cache is cleared
- if `version` isn’t set, an MD5 hash of the `gatsby-*` file contents is used to invalidate the cache
- omitting the `version` field is recommended for local plugins
- `gatsby-browser.js` — usage details are in the [browser API reference](/docs/browser-apis/)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth being explicit that these three files are optional? Similar to the [required] note on package.json

- `gatsby-node.js` — usage details are in the [Node API reference](/docs/node-apis/)
- `gatsby-ssr.js` — usage details are in the [SSR API reference](/docs/ssr-apis/)

## Local plugins

If a plugin is only relevant to your specific use-case, or if you’re developing a plugin and want a simpler workflow, a locally defined plugin is a convenient way to create and manage your plugin code.

Place the code in the `plugins` folder in the root of your project like this:

```
plugins
└── my-own-plugin
└── package.json
```

**NOTE:** You still need to add the plugin to your `gatsby-config.js`. There is no auto-detection of local plugins.

Like all `gatsby-*` files, the code is not being processed by Babel. If you want
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*is not processed

Kill "being"

to use JavaScript syntax which isn't supported by your version of Node.js, you
can place the files in a `src` subfolder and build them to the plugin folder
root.
41 changes: 4 additions & 37 deletions docs/docs/plugins.md
Original file line number Diff line number Diff line change
Expand Up @@ -37,47 +37,14 @@ module.exports = {

Plugins can take options. Note that plugin options will be stringified by Gatsby, so they cannot be functions.

See each plugin page below for more detailed
documentation on using each plugin.
## Creating your own plugins

## Locally defined plugins

When you want to work on a new plugin, or maybe write one that is only relevant
to your specific use-case, a locally defined plugin is more convenient than
having to create an NPM package for it.

You can place the code in the `plugins` folder in the root of your project like
this:

```
plugins
└── my-own-plugin
├── gatsby-node.js
└── package.json
```

You still need to add the plugin to your `gatsby-config.js` like for plugins
installed from NPM.

Each plugin requires a package.json file, but the minimum content is just an
empty object `{}`. The `name` and `version` fields are read from the package
file. The name is used to identify the plugin when it mutates the GraphQL data
structure. The version is used to clear the cache when it changes.

For local plugins it is best to leave the version field empty. Gatsby will
generate an md5-hash from all gatsby-\* file contents and use that as the
version. This way the cache is automatically flushed when you change the code of
your plugin.

If the name is empty it is inferred from the plugin folder name.

Like all gatsby-\* files, the code is not being processed by Babel. If you want
to use JavaScript syntax which isn't supported by your version of Node.js, you
can place the files in a `src` subfolder and build them to the plugin folder
root.
If you’d like to create a custom Gatsby plugin, check out the [plugin authoring guide](/docs/plugin-authoring/).

## Official plugins

For usage instructions and options, see the plugin repo (linked below).

* [gatsby-plugin-aphrodite](/packages/gatsby-plugin-aphrodite/)
* [gatsby-plugin-canonical-urls](/packages/gatsby-plugin-canonical-urls/)
* [gatsby-plugin-catch-links](/packages/gatsby-plugin-catch-links/)
Expand Down
2 changes: 2 additions & 0 deletions www/src/pages/docs/doc-links.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,8 @@
link: /docs/migrating-from-v0-to-v1/
- title: Path Prefix
link: /docs/path-prefix/
- title: Plugin Authoring
link: /docs/plugin-authoring/
- title: Proxying API Requests
link: /docs/api-proxy/
- title: Using CSS-in-JS library Glamor
Expand Down