Closed nlf closed 5 years ago
flagging @marsup @arb and @hueniverse as they're the maintainers of the only three modules i can think of off the top of my head that currently support extensions
Sure as long as I don't have to be the one maintaining it for catbox.
Sounds good to me. I feel as though it could also be simple enough to pull it out of a section of the readme, but given the direction taken with API.md it seems reasonable that we would continue the approach of adding files. Do we imagine that PLUGINS.md
would have a link in the readmes?
This should be ONLY for official "aka under the hapijs org" plugins/extensions. Was that your thought? Cause that's my thought.
yeah that's my current plan, same as for bringing in the API.md
Sounds like a great task for the "new-contributor" label 👍
In my case I thought of the extended universe, I don't plan to go crazy on joi extensions in the org unless some of them make sense for hapi itself.
oh, right, i should clarify. i meant that the PLUGINS.md
file would exist for repos in the hapijs org. it would contain plugins/extensions that exist anywhere. it's up to the maintainer of that module (or some other maintainer in the org) to merge pull requests to that file, much like we currently do for the site.
Currently extensions for good are listed with the other plugins under "logging", and extensions for catbox (and catbox itself) are completely missing. Joi also supports extensions now, so it's time to start thinking about how to best go about listing these things.
It certainly makes sense to group these extensions with the module that they belong to, so @Marsup had the idea of creating a
PLUGINS.md
file in the repo. Here's what we're thinking:If your module supports extensions, create a
PLUGINS.md
file at the root of the repo, next toAPI.md
which I'll also be bringing in soon (you did create that, right?).The contents of
PLUGINS.md
should be formatted much like a simplified version of awesome-nodejs without the table of contents, for example:This file will be pulled in and displayed as a subcategory under your module to make it clear that these are extensions rather than standalone plugins. This also enables module maintainers to keep this list up to date independent of the site, and puts documentation of these extensions closer to the place where they're being used. People who use joi, for example, aren't necessarily using hapi, so they may never think to check hapijs.com (or its repository) for extensions.
Any thoughts? Arguments? Alternate ideas? Additional alliteration?