lemon-package-generator v1.0.2

lemon-package-generator

optionated template

Why?

lemon-package-generator ensures all the rules given below are followed:

• provide your users with a helpful .env.example
  • TODO: update README to include a default paragraph to describe what to do with .env.example
• use dotenv for configuration, following the tenets of a twelve-factor app
  • only use dotenv in your application entry point, or library if applicable.
• use container mode in travis and leverage folder caching.
• use mocha for testing
• use istanbul to generate coverage reports
• publish coverage reports to codeclimate (requires configuring travis with the appropriate CODECLIMATE_REPO_TOKEN)
• use standard and echint for linting files
• enforce standard & echint by running on pretest
• always generate code coverage reports by running istanbul on posttest
• use commander to provide a CLI (Command Line Interface) when applicable
• use debug-log to provide helpful debugging messages without the use of console.log
• use EditorConfig files enforced by echint
• keep your package lean, only include useful files for developers when running npm install (see package.json + .npmignore files)
• use the most permissive open source license (currently ISC)
• always expose your package's library modules (see folder tree below)

• follow a preferred folder tree & npm's default expected file naming:

  /package-name/
  ├── bin
  │   └── package-name
  ├── docs
  │   ├── API.md
  │   └── INSTALL.md
  ├── .editorconfig
  ├── .env.example
  ├── .gitattributes
  ├── .gitignore
  ├── .jshintrc
  ├── lib
  │   └── index.js
  ├── LICENSE
  ├── .npmignore
  ├── package.json
  ├── README.md
  ├── server.js
  ├── src
  │   └── index.js
  ├── test
  │   ├── fixtures
  │   └── index.js
  └── .travis.yml

  • /docs/INSTALL.md: detailed instructions for anything beyond npm install
  • /docs/API.md: if your package exposes an language API, or as an application a web API, document here.
  • /lib: library files: all common business logic, use this folder as heavily as possible, e.g. Express routers
  • /src: application files: the application logic (if any), e.g. Express Server Setup
  • server.js: your application entry point (this is the default target of npm start), use for initializing and managing the application state
  • .jshintrc: this is only useful for running through an online quality check tool e.g. codeclimate which does not follow standard and has no configuration option for eslint yet.

Post Generating

• remove any optional files and folders based on the type of project (e.g. ./bin, ./src, ./server.js)
• unless directly affecting your logic, don't write custom logic for clustering, use pm2 instead
• only use node v0.12.x and above (unless open-source, start with: node v0.10)
• use npm scripts when possible to automate install and build steps:
  • e.g. "postinstall": "bower install"
  • e.g. "beforestart": "gulp build"

Work in progress...

This is a work in progress, and will likely be in this state forever! I will be updating this frequently as common practices change over time, or as I learn new trick.

please reach out to share some feedback & contribute!

Install

npm install --save lemon-package-generator

Usage

  Usage: lemon-package-generator [options] name path
  Options:
    -h, --help          output usage information
    -V, --version       output the version number
    -a, --author        Author Name
    -d, --description   description
    -e, --author-email  Author Email
    -g, --github        Github Username
    -i, --install       Install Dependencies
    -q, --quiet         hide npm install output
    -w, --website       Author Website

API

lemon-package-generator(options)

var generator = require('lemon-package-generator')
var options = {
    name: 'my-awesome-package',
    target: '~/Projects/my-awesome-package'
}
generator(options)
    .then(function (files) {
        console.log(files) /*-> [array of files created] */
    })
    .catch(function (err) {
        console.error(err)
    })

options