-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
docs: improve documentation for plugin authors #4272
Conversation
- Link to plugin docs - Link to API spec re gatsbyjs#4266
Deploy preview for gatsbygram ready! Built with commit ce9b870 |
Deploy preview for gatsbygram ready! Built with commit bab8c3d |
- removes local plugin docs - adds link to plugin authoring (where local plugin docs were moved) re gatsbyjs#4266
- add naming convention explanations and examples - add core plugin concepts as bullet points - add list of files Gatsby tries to find in a plugin - explain local plugin development re gatsbyjs#4266
Super awesome stuff. @benjaminhoffman looks like Jason has got a great "how to build a plugin" guide here, so since you mentioned wanting to write something like this, maybe you'd like to hop in here and see what you think. Perhaps you could try these instructions and then offer feedback on how they work out for you?? What they are doing well and what they're missing! |
I like this. Definitely heading in the right direction. I'm still learning about how to build a plugin but so far, the PR looks great to me! |
docs/docs/plugin-authoring.md
Outdated
installed from NPM. | ||
|
||
At a minimum, 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first sentence mentions that "the minimum content is just an empty object". The following sentence then explains what is read from package.json. I find this a little confusing—first it's "okay to be empty", but then "things are read" only fully makes sense to me after advancing to the following paragraphs. I think an addition to the second sentence would help (me ;-)), but I'm not sure if the following is the best way to go:
If present, the
name
andversion
fields are read from the package file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point — let me add what the default values are.
Adding a reference to #4244 so anyone who finds that via Google can make their way to this PR and the relevant documentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! I've added some thoughts - feel free to use or ignore as you see fit. 😄
docs/docs/plugin-authoring.md
Outdated
|
||
- Every Gatsby plugin is a standalone npm package | ||
- At minimum, a `package.json` is required | ||
- Plugins can be used locally (see [local plugins](#local-plugins) below) or published to npm as packages |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this concept conflict with the first concept "Every Gatsby plugin is a standalone npm package"?
Maybe the first concept could be something like "A Gatsby plugin is a set of files that can modify Gatsby's behaviour"?
docs/docs/plugin-authoring.md
Outdated
- **`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` | ||
- **`gatsby-transformer-*`** — a transformer plugin converts data from one format to another (e.g. CSV to JSON). Use this naming convention | ||
- Example: `gatsby-transformer-yaml` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to add a bit more info on when you'd create a transformer vs a source plugin? Maybe this isn't the right place to write about that, but it's something that's a bit of a grey area to me.
docs/docs/plugin-authoring.md
Outdated
|
||
- `package.json` — [required] used to find the `name` and `version` fields (both optional) | ||
- this can be an empty object (`{}`) for local plugins | ||
- `gatsby-browser.js` — usage details are in the [browser API reference](/docs/browser-apis/) |
There was a problem hiding this comment.
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
docs/docs/plugin-authoring.md
Outdated
└── package.json | ||
``` | ||
|
||
**NOTE:** You still need to add the plugin to your `gatsby-config.js` like for plugins |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
like reads a bit strangely to me. Would any of the following work better? the same as, similarly to, as you would, or something else?
- Add link to “create a source plugin” docs - Clarify optional vs. required files - Clarify how `package.json` works and what default values are - Clean up local plugin `gatsby-config.js` note - Remove duplicate explanation of `package.json` re gatsbyjs#4266
- Clarify that plugins can run as npm packages or local files re gatsbyjs#4266
@m-allanson Addressed your comments — thanks for those! |
I'm thinking we should move the README boilerplate to its own issue and look at getting this PR merged as-is (or with whatever edits have yet to come in). @shannonbux @benjaminhoffman @m-allanson @fk @KyleAMathews Any opposition to splitting off the README? |
docs/docs/plugin-authoring.md
Outdated
@@ -6,7 +6,7 @@ Creating custom plugins in Gatsby is a breeze with our straightforward authoring | |||
|
|||
## Core Concepts | |||
|
|||
- Each Gatsby plugin can installed as an npm package or as a [local plugin](#local-plugins) | |||
- Each Gatsby plugin can be installed as an npm package or as a [local plugin](#local-plugins) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦♂️ Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fantastic! Creating plugins is something every site should do and this is a great start to making that doable for folks.
docs/docs/plugin-authoring.md
Outdated
title: Plugin Authoring | ||
--- | ||
|
||
Creating custom plugins in Gatsby is a breeze with our straightforward authoring process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've been following @robwierzbowski's suggestion to avoid indicating something is "easy" as that can intimidate newer developers for whom everything is complicated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Another way to word this could be:
The Gatsby API is open and flexible and the number of plugins created by community members is growing. Follow these steps to create a custom plugin in Gatsby.
I don't know if that is gobbledygook language since I'm not a programmer. The essence would be to emphasize how Gatsby is meant to be open to plugins. It was built to expect them. Or something like that. Just a tone that invites people to experiment and realize that there is a lot of potential for an awesome plugin ecosystem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, thanks for remembering! My two cents:
Gatsby is designed to be extensible. One of the best ways to add functionality to Gatsby is through our plugin system. (maybe some examples of what is a good fit for a plugin...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. I'm leaning toward @robwierzbowski's wording, and I'll work in some examples of good candidates for plugins.
docs/docs/plugin-authoring.md
Outdated
|
||
## Core Concepts | ||
|
||
- Each Gatsby plugin can be installed as an npm package or as a [local plugin](#local-plugins) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Capitalize NPM
There was a problem hiding this comment.
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/ 😕
docs/docs/plugin-authoring.md
Outdated
## Core Concepts | ||
|
||
- Each Gatsby plugin can be installed as an npm package or as a [local plugin](#local-plugins) | ||
- At minimum, a `package.json` is required |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove "At minimum"
docs/docs/plugin-authoring.md
Outdated
|
||
- Each Gatsby plugin can be installed as an npm package or as a [local plugin](#local-plugins) | ||
- At minimum, a `package.json` is required | ||
- A plugin has access to the the Gatsby [Node](/docs/node-apis/), [SSR](/docs/ssr-apis/), and [browser](/docs/browser-apis/) APIs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd put it "Plugins implement Gatsby APIs for [Node]..."
docs/docs/plugin-authoring.md
Outdated
- **`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` | ||
- Docs: [create a source plugin](/docs/create-source-plugin/) | ||
- **`gatsby-transformer-*`** — a transformer plugin converts data from one format to another (e.g. CSV to JSON). Use this naming convention |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"A transformer plugin converts data from one format into JavaScript objects"
I can't think of any reason why a transformer plugin wouldn't ever transform data directly into JavaScript objects. It could happen but it's unlikely.
docs/docs/plugin-authoring.md
Outdated
- **`gatsby-transformer-*`** — a transformer plugin converts data from one format to another (e.g. CSV to JSON). Use this naming convention | ||
- Example: `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. | ||
- Example: `gatsby-remark-images` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The examples should link to their package page.
docs/docs/plugin-authoring.md
Outdated
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove "can"
docs/docs/plugin-authoring.md
Outdated
## Local 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*because a locally defined
docs/docs/plugin-authoring.md
Outdated
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: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey hey! Nice use of a full sentence before a colon. I'm not a grammar tight wad (hopefully) but did find it interesting to learn last year that I had been using colons ineffectively for years. They are most effective after full sentences and hardly anyone does that
docs/docs/plugin-authoring.md
Outdated
``` | ||
|
||
**NOTE:** You still need to add the plugin to your `gatsby-config.js` like for plugins | ||
installed from NPM. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*like you would for plugins
docs/docs/plugin-authoring.md
Outdated
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*empty,
docs/docs/plugin-authoring.md
Outdated
- Example: `gatsby-source-contentful` | ||
- **`gatsby-transformer-*`** — a transformer plugin converts data from one format to another (e.g. CSV to JSON). Use this naming convention | ||
- Example: `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. |
There was a problem hiding this comment.
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?
docs/docs/plugin-authoring.md
Outdated
title: Plugin Authoring | ||
--- | ||
|
||
Creating custom plugins in Gatsby is a breeze with our straightforward authoring process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Another way to word this could be:
The Gatsby API is open and flexible and the number of plugins created by community members is growing. Follow these steps to create a custom plugin in Gatsby.
I don't know if that is gobbledygook language since I'm not a programmer. The essence would be to emphasize how Gatsby is meant to be open to plugins. It was built to expect them. Or something like that. Just a tone that invites people to experiment and realize that there is a lot of potential for an awesome plugin ecosystem.
docs/docs/plugins.md
Outdated
@@ -40,41 +40,9 @@ Plugins can take options. Note that plugin options will be stringified by Gatsby | |||
See each plugin page below for more detailed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just for less redundancy, perhaps: "see the links below for instructions on how to use each plugin"
Love the attention to docs here! You're the best 🙏🏼🙌🏼 |
This rewording seems excellent to me, @robwierzbowski
…On Wed, Feb 28, 2018 at 2:07 PM, Rob Wierzbowski ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In docs/docs/plugin-authoring.md
<#4272 (comment)>:
> @@ -0,0 +1,61 @@
+---
+title: Plugin Authoring
+---
+
+Creating custom plugins in Gatsby is a breeze with our straightforward authoring process.
Hey, thanks for remembering! My two cents:
Gatsby is designed to be extensible. One of the best ways to add
functionality to Gatsby is through our plugin system. (maybe some examples
of what is a good fit for a plugin...)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4272 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ae9o2sEpAdSxmgtflQq1llKy6sG0aY4aks5tZb__gaJpZM4SVueg>
.
|
- remove reference to plugins being “easy” - build off @robwierzbowski’s wording - add examples of what plugins can do re gatsbyjs#4266
@jlengstorf oh huh. Yeah, I guess we go with their official thing then!
…On Wed, Feb 28, 2018 at 3:44 PM, Jason Lengstorf ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In docs/docs/plugin-authoring.md
<#4272 (comment)>:
> @@ -0,0 +1,61 @@
+---
+title: Plugin Authoring
+---
+
+Creating custom plugins in Gatsby is a breeze with our straightforward authoring process.
+
+## Core Concepts
+
+- Each Gatsby plugin can be installed as an npm package or as a [local plugin](#local-plugins)
Their official branding appears to keep it lowercase:
https://www.npmjs.com/ 😕
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4272 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ae9o2jcICWvxqM8rpI38UuebC4K1K3vKks5tZdbKgaJpZM4SVueg>
.
|
- update wording per @KyleAMathews feedback - clarify transformer description - link to example plugins - fix grammar mistakes re gatsbyjs#4266
@shannonbux @KyleAMathews Addressed your feedback and pushed up changes. Let me know if you see anything else! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple other small needed tweaks I found
docs/docs/plugin-authoring.md
Outdated
|
||
## Core Concepts | ||
|
||
- Each Gatsby plugin can be installed as an npm package or as a [local plugin](#local-plugins) |
There was a problem hiding this comment.
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.
docs/docs/plugin-authoring.md
Outdated
|
||
**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 |
There was a problem hiding this comment.
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"
All set, @KyleAMathews! |
Nicely done, thanks! |
Wow it's amazing to see this getting done. Way to go, @jlengstorf et al~!
…On Wed, Feb 28, 2018 at 5:41 PM, Kyle Mathews ***@***.***> wrote:
Nicely done, thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4272 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Ae9o2neTs67Ukkr3QO_yDT9mp8t7ZmhRks5tZ0OfgaJpZM4SVueg>
.
|
Opening a PR early to allow feedback early and often.
Goals for this PR:
gatsby-node.js
) to the authoring page- [ ] Add a boilerplate README for a Gatsby plugin to the authoring page(this was moved to [docs] Add template for plugin READMEs #4284)re #4266