Awesome

clinton

JavaScript project style linter

Install

$ npm install --save clinton

Usage

const clinton = require('clinton');

clinton.lint('/Users/sam/projects/clinton', {rules: {'license': ['error', 'MIT']}}).then(validations => {
	console.log(validations);
	/*
		[
			{
				ruleId: 'license',
				severity: 'error',
				message: 'License is not of type MIT (http://www.opensource.org/licenses/MIT).'
			}
		]
	*/
});

Instead of passing the rules as an option, you can also add them to your package.json file.

{
	"name": "foo",
	"license": "ISC",
	"clinton": {
		"rules": {
			"license": ["error", "MIT"]
		}
	}
}

API

.lint(path, [options])

path

Type: string

Project path.

options

rules

Type: object

Override any of the default rules.

inherit

Type: boolean<br> Default: true

Inherit from the default rules. Set to false if you want to start with a clean sheet.

plugins

Type: string[]

List of plugin names.

ignores

Type: string[]

Paths in .gitignore are ignored by default. Additional ignores can be added here.

cwd

Type: string

Current working directory when linting local projects.

CLI

    Usage
      $ clinton [<path>]

    Options
      --no-inherit  Prevent inheriting from the default rules.
      --ignores     Ignore files. Can be added multiple times.
      --fix         Automatically fix problems.

    Examples
      $ clinton
        .editorconfig
        ⚠  Use .editorconfig to define and maintain consistent coding styles between editors.     editorconfig

        1  warning

      $ clinton ~/projects/project
        license
        ✖  No MIT license found.  license-mit

        1  error

Tip: Use the config in package.json whenever possible for maintainability and to make it easier for eventual other tools to read the config.

Rules

ava - Enforces the use of AVA. (fixable)
cli - Enforces the existance and executability of the cli file.
editorconfig - Enforces the use and rules of EditorConfig.
filename-case - Enforce a case style for filenames.
gitignore - Enforce the use of .gitignore. (fixable)
gulp - Enforces the correct devDependencies when Gulp is detected.
keywords - Enforces the use of keywords in package.json.
license - Enforce the use of a specific license.
max-depth - Enforce the maximum depth of the directory structure.
no-callback - Enforces the use of promises instead of callbacks.
no-dup-keywords - Enforce not having duplicate keywords in package.json. (fixable)
no-empty-keywords - Enforce not having empty keywords in package.json. (fixable)
no-git-merge-conflict - Prevents having Git merge conflict markers.
pkg-dependency-order - Enforces alphabetical order of dependencies and devDependencies in package.json. (fixable)
pkg-description - Enforces the description to start with a capital letter and not end with a dot. (fixable)
pkg-engine - Enforces the use of a engines.node field in package.json.
pkg-main - Enforces the existance of the main file.
pkg-name - Enforces a valid package name.
pkg-normalize - Enforces package normalization. (fixable)
pkg-property-order - Enforces order of properties in in package.json. (fixable)
pkg-schema - Enforces a valid package.json.
pkg-shorthand-repository - Enforces the use of the shorthand repository URL. (fixable)
pkg-user-order - Enforces order of properties in user objects in package.json. (fixable)
readme - Enforce having a readme.
test-script - Enforces the use of tests.
travis - Enforces the correct versions in .travis.yml. (fixable)
use-travis - Enforces the use of Travis CI.
valid-properties - Enforce recommended properties in package.json.
valid-version - Enforces a valid version identifier in package.json.
xo - Enforces the use of XO. (fixable)

Plugins

Everyone can create plugins or custom rules that can be validated with Clinton. The name of the plugin should be clinton-plugin-* where * is the name of the plugin.

Example

Let's create a clinton-plugin-file-exists rule that checks if the file provided as argument really exists.

'use strict';
module.exports = ctx => {
	const fileName = ctx.options[0];

	if (!ctx.files.includes(fileName)) {
		ctx.report({
			message: `File ${fileName} does not exist.`
		});
	}
};

You can also return a promise if you are performing asynchronous operations.

You can wrap this up in a project, publish it to npm and install it in every project where you want to check if a file in your project really exists.

{
	"name": "Unicorn",
	"description": "My unicorn package",
	"version": "1.0.0",
	"scripts": {
		"test": "clinton"
	},
	"devDependencies": {
		"clinton": "*",
		"clinton-plugin-file-exists": "1.0.0"
	},
	"clinton": {
		"plugins": [
			"file-exists"
		],
		"rules": {
			"file-exists": ["error", "index.js"]
		}
	}
}

When running npm test, clinton will execute your plugin and will use index.js as the option argument. The first that is passed to the plugin, error in this example, indicates the severity of the error.

gh-lint-brainstorm - Brainstorming repository for this module