From 0469094bb8c4c54e5bb8b2cf5994dd72fa8db713 Mon Sep 17 00:00:00 2001 From: contra Date: Wed, 21 Sep 2016 12:07:51 -0400 Subject: [PATCH] clarify what an API should look like --- docs/writing-a-plugin/guidelines.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/writing-a-plugin/guidelines.md b/docs/writing-a-plugin/guidelines.md index 158b1f80b..79cb3e703 100644 --- a/docs/writing-a-plugin/guidelines.md +++ b/docs/writing-a-plugin/guidelines.md @@ -22,6 +22,9 @@ - Testing a gulp plugin is easy, you don't even need gulp to test it - Look at other plugins for examples 1. Add `gulpplugin` as a keyword in your `package.json` so you show up on our search +1. Your plugin API should be a function that returns a stream + - If you need to store state somewhere, do it internally + - If you need to pass state/options between plugins, tack it on the file object 1. Do not throw errors inside a stream - Instead, you should emit it as an **error** event. - If you encounter an error **outside** the stream, such as invalid configuration while creating the stream, you may throw it.