Browsable/searchable list of starters

[KyleAMathews]

The Gatsby website should have a list of starters.

This would be derived from a YAML file within this repo.

People can create a PR to add their starter.

There should be tests which:

1. validate that each site has necessary fields e.g. title, description, url to demo site, url to valid github repo, screenshot, authors w/ emails, other metadata (e.g. tags, added date, tech uesd (Sass/less/etc), stars, etc.)
2. validate that starter can be installed and built without errors.

These two tests will ensure the quality of starters remain high without a lot of manual intervention.

Perhaps when a starter test fails, auto email the author?

Setup http://greenkeeper.io/ for each community starter?

Perhaps run install + build tests weekly and then generate a screenshot from that? On a failure, create a PR on their repo to update. If they don't fix by the following week, comment them out of the community listing until they've fixed themselves. If they fix their starter before the following week, they can manually create a PR against Gatsby to re-add themselves.

[KyleAMathews]

Starters are a key part of where I see Gatsby going.

Great starters are key because:

1. They vastly speed up the initial time-to-value.
2. Give non-programmers a way to play.
3. Long-term they help disseminate best-practices.

[KyleAMathews]

@fson suggested on Slack that instead of maintaining a central yaml file, just standardize around a "gatsby-starter" tag in package.json. 👍 from me for that.

[kevinsimper]

@KyleAMathews

package.json

That would only work if the starter is published to npm but the starter is hosted on github?

[KyleAMathews]

No the indexer could read the package.json from github just fine.

[kevinsimper]

But then you still need to provide a central place for telling about the github repo with that package.json

[KyleAMathews]

Right, starters will be manually added here via PRs.

[gesposito]

It's actually possible to scan the whole npm registry looking for specific tags inside the packages.
I have a toy project (not a Node.js developer... yet?) that does that. It would need a server for running the "live" version of it, otherwise it would need to be triggered on demand.
It's a bit of work but it would discover any starter published on npm.

Not sure about Github's API.

[KyleAMathews]

There might (hopefully) be a day where there's too many Gatsby starters to easily manually curate but I'd guess we're a long ways off from that :) So for now, creating a registry maintained here seems like a reasonable approach. So until then, adding Github repos to the registry which then get scanned for metadata (most likely added to the package.json) and added to the Gatsby website seems like the right approach.

[kevinsimper]

@gesposito https://www.npmjs.com/browse/keyword/http :) it pretty simple, but gatsby starters is git repos and not npm modules

@KyleAMathews 👍

[KyleAMathews]

Oh, I did forget about #20. If/when that lands, then the "base" sites would almost certainly be installed via NPM. E.g. you'd install the gatsby-blog-base package which would provide the base _template + index files and you'd just need to add markdown files for posts. But those (whatever they're called) would always be treated differently than starters. Starters are meant to "start" off a site. They're malleable etc. "Base" sites are more like Wordpress themes where they set the structure, etc. of your site so you just need to add content.

[KyleAMathews]

Some CLI inspiration https://github.com/drjekyllthemes/drjekyll

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[KyleAMathews]

closing this issue as active discussion has moved to #3003