hal (-) *rc

Hal should be, well, linted.

Why

Node modules tend to be many.
One tends to repeat, oneself.
Over and over copy / pasting.
Even with the best practices.

For one example this could be the perfect implementation of your code linting best practices, as described in Henrik Joreteg's Human JavaScript / code for humans.

What

1. Make sourcegate more conveniently configurable, especially in the context of beverage, for the purpose of writing .*rc files that will setup hinting and linting rules for a project - without copy / paste. In this context hal-rc simply gets the options ready for calling sourcegate with.

2. Offer gulpfriendly task(s) creation, while keeping it optional - i.e. call without the gulp argument and build your own workflow using whatever approach / other tools you may prefer instead.

3. A place where I keep my own linting rules and preferences - in rc/*. This would be irrelevant for anybody else though feel free to follow / tweak my coding standard if you like. Unless of course we collaborate on some projects that are based on these settings.

Use

Scenario 1:

var options = require('hal-rc')({
  // options listed next
})
// call sourcegate with the above, see the tests about how

Scenario 2:

require('hal-rc')({
  // options listed next
}, require('gulp'))
// use gulp cli for running the sourcegate tasks

Configure:

• sourcegate: [] creates tasks that write configuration files, documented next
• sourcegateRx: {} abbreviation for sourcegateRecipeDefaults so one can skip stuff like sources: {node: true} for each jshint-linted project, skip the defaults with sourcegate: [{recipe: 'jshint', sources: {}}] for example, or override with sourcegateModule / module config
• sourcegateModule: 'a-node_modules-module-name' optional like everything else
• sourcegatePrefix: '.'will look for".#{recipe}rc"`, it can also be a path
• sourcegatePreset: "airbnb" for example, in some cases there are presets across tools, this sets a default one for configuration DRY-ness; presets of tools installed in the project's node_modules have priority over presets form sourcegateModule's node_modules, this way a project can have its own version of presets
• sourcegateWatch: true will create a sourcegate:watch task, if hal-rc is handed gulp via the second argument

The above options can be used to setup configuration files from a template to the project's root with possible overrides. This is done with the sourcegate module and some example files would be: .jshintrc, .jscsrc, .eslintrc, etc. If there is a package in node_modules that contains some / many / most / all your baseline defaults for coding style preferences / standards, sourcegateModule will tell beverage about it so the config is DRYer. Or each template can set its own individual module / path. It could be a published module, or a git repo in devDependencies. Beverage offers convenient setup for tools that use json config files, for example:

• jscs
• jshint
• eslint

These tools are here called recipes. Any tool that looks for its configuration in a ".#{tool}rc" file, in a project's root dir - is automatically supported as a recipe. The config would look like:

{
  recipe: 'name', // a tool's name
  module: 'name', // overrides the sourcegateModule default
  prefix: '.', // what goes between module and "#{recipe}rc"
  preset: 'name', // this is only relevant for jscs, or "airbnb" so far
  sources: [], // sourcegate's first argument - stuff to merge
  sources: {}, // shorthand for overrides that don't come from a file
  options: {} // handed to sourcegate
}

Some tools, such as jscs have presets, use the preset option for easy config. In this case, jscs would have to be a dependency of the project using beverage, or the configured module, checked in precisely this order.

The recipe, module, prefix and preset options are merely conveniences.

One can always fallback to sourcegate options. The minimum needed in such a case is:

{
  sources: [
    // one or more things to merge
  ],
  options: {write: {path: 'name-me.json'}} // if not ".#{tool}rc"
}

Test

npm test

Unlicensed

This is free and unencumbered public domain software. For more information, see UNLICENSE.