|
| 1 | +# PostHTML Plugins Guideline |
| 2 | + |
| 3 | +A PostHTML plugin is a function that receives and, usually, transforms a HTML AST from the PostHTML parser. HTML AST has the PostHTML Tree format. [Read more about PostHTML Tree](https://github.com/posthtml/posthtml/blob/master/docs/tree.md). |
| 4 | + |
| 5 | +The rules below are mandatory for all PostHTML plugins. |
| 6 | + |
| 7 | +## Clear name with posthtml- prefix |
| 8 | + |
| 9 | +The plugin’s purpose should be clear just by reading its name. If you wrote a transpiler for HTML Custom Elements, posthtml-custom-elements would be a good name. If you wrote a plugin to support BEM, posthtml-bem would be a good name. |
| 10 | + |
| 11 | +The prefix posthtml- shows that the plugin is part of the PostHTML ecosystem. |
| 12 | + |
| 13 | +This rule is not mandatory for plugins that can run as independent tools, without the user necessarily knowing that it is powered by PostHTML. |
| 14 | + |
| 15 | +## Do one thing, and do it well |
| 16 | + |
| 17 | +Do not create multitool plugins. Several small, one-purpose plugins bundled into a plugin pack is usually a better solution. |
| 18 | + |
| 19 | +## Plugin must be tested |
| 20 | + |
| 21 | +A CI service like Travis is also recommended for testing code in different environments. You should test in (at least) Node.js 0.12 and stable. |
| 22 | + |
| 23 | +## Use only the public PostHTML API |
| 24 | + |
| 25 | +PostHTML plugins must not rely on undocumented properties or methods, which may be subject to change in any minor release. The public API is described in [API docs](https://github.com/posthtml/posthtml/blob/master/docs/api.md). |
| 26 | + |
| 27 | +## Document your plugin in English |
| 28 | + |
| 29 | +PostHTML plugins must have their README.md written in English. Do not be afraid of your English skills, as the open source community will fix your errors. |
| 30 | + |
| 31 | +Of course, you are welcome to write documentation in other languages; just name them appropriately (e.g. README.ja.md). |
| 32 | + |
| 33 | +## Include input and output examples |
| 34 | + |
| 35 | +The plugin's README.md must contain example input and output HTML. A clear example is the best way to describe how your plugin works. |
| 36 | + |
| 37 | +The first section of the README.md is a good place to put examples. See [posthtml-expressions](https://github.com/posthtml/posthtml-exp) for an example. |
| 38 | + |
| 39 | +Of course, this guideline does not apply if your plugin does not transform the HTML. |
| 40 | + |
| 41 | +## Maintain a changelog |
| 42 | + |
| 43 | +PostHTML plugins must describe the changes of all their releases in a separate file, such as CHANGELOG.md, History.md, or [GitHub Releases](https://help.github.com/articles/creating-releases/). Visit [Keep A Changelog](http://keepachangelog.com/) for more information about how to write one of these. |
| 44 | + |
| 45 | +Of course, you should be using [SemVer](http://semver.org/). |
| 46 | + |
| 47 | +## Include posthtml-plugin keyword in package.json |
| 48 | + |
| 49 | +PostHTML plugins written for npm must have the posthtml-plugin keyword in their package.json. This special keyword will be useful for feedback about the PostHTML ecosystem. |
| 50 | + |
| 51 | +For packages not published to npm, this is not mandatory, but is recommended if the package format can contain keywords. |
0 commit comments