npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

clinton

v0.14.0

Published

JavaScript project style linter

Downloads

359

Readme

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 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.

Related

License

MIT © Sam Verschueren