generator-lit

scaffold lit node modules

Write your modules with the newest features, yet support the oldest systems. Run yo lit and you'll be left with everything you need to ship your next big idea!

Features:

• code with es2016+
• transpile back for v0.10+ support
• optional cli (separates the api and cli into one lerna project)
• optional code coverage with nyc
• optional coverage uploading with Coveralls

Install

$ npm install --global yo generator-lit

Usage

With yo:

$ yo lit

There are multiple command-line options available:

$ yo lit --help

  Usage:
    yo lit [options]

  Options:
    --help          # Print the generator's options and usage
    --skip-cache    # Do not remember prompt answers                       Default: false
    --skip-install  # Do not automatically install dependencies            Default: false
    --org           # Publish to a GitHub organization account
    --cli           # Add a CLI                                            Default: true
    --coverage      # Add code coverage with nyc                           Default: true
    --coveralls     # Upload coverage to coveralls.io (implies --coverage) Default: true

The --org option takes a string value (i.e. --org=avajs). All others are boolean flags and can be negated with the no prefix (i.e. --no-coveralls). You will be prompted for any options not passed on the command-line.

FAQ

What does it mean to "code in es2016+"?

All lit scaffolded modules are stranspiled with babel's es2015 and stage-2 presets - which includes stage-3, and stage-4.

So you can finally use the newest features with no configuration:

const sum = (...numbers) => {
  return numbers.reduce((a, b) => {
    return a + b;
  });
}

console.log(sum(1, 2, 3, 4, 5)); // 15

Your module's interaction with babel is very simple:

.babelrc

{
  "presets": [
    "es2015",
    "stage-2"
  ]
}

Add to, remove, modify, or delete babel entirely. Either way it's the way of life until all of our everyday systems run the coolest new features. Read more about babel

Why are the api and cli two separate modules in one repo?

One word: modularity.

More good reasons:

1. When user's want your api, they don't need to also download the cli
2. Install time for them together is sometimes the exact same speed as just one
3. Eases tracking down where bug's lie

License

MIT © Dawson Botsford