node package manager
We need your input. Help make JavaScript better: Take the 2017 JavaScript Ecosystem survey »

clinton

clinton

Build Status: Linux Build status: Windows Coverage Status

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
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 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": ["error", "index.js"]
        }
    }
}

When running npm test, clinton will execute your plugin and will use index.js as the option argument. The first argument error indicates the severity of the error.

Related

License

MIT © Sam Verschueren