cloverfield-tools/cloverfield

Scaffolds and cf CLI Meta issue

Opened this issue · 10 comments

CLI

  • The CLI will be a binary called cf which can be installed globally. Packages that depend on it should install it locally as a devDependency.

API

If cf is invoked with missing arguments, it should:

  • display usage
  • prompt for missing arguments, one at a time

build

Create a new package from a Cloverfield scaffold. Scaffolds should be cached locally. See Scaffold Conventions

Usage

cf build <scaffold-name>

TODO:

@nkbt Now that the boilerplates are starting to shape up, are you interested in working on this?

nkbt commented

By all means, always wanted to build one for myself =)

Great. I've created the Scaffold conventions doc. Feel free to take on the build tooling at your convenience.

This is looking great so far. I will be a little busy the next couple days but I plan on helping out!

https://twitter.com/sethetter/status/618779021526970368

This is worth calling out. My primary problem with yeoman is the ecosystem signal to noise ratio. It got so bad, when I thought about scaffold solutions and realized we could probably just wrap yeoman, the idea of even having the project associated with yeoman mentally was bad enough it was worth starting from scratch.

How do we prevent the inevitably terrible scaffolds from turning off users?

I think the answer is that the CLI should have first class search and discovery for curated scaffolds, and no search/discovery for community scaffolds. If people want to search past the cf whitelist, they can use npm search, Google, or GitHub search.

We're not yeoman and we're not npm, where you search for needles in a giant haystack. We're a tool for eliminating choices, not adding to them.

@nkbt It's been a while since we saw any activity here. Where are we on turning prod-module-boilerplate into a cf scaffold?

nkbt commented