ECLint

Introduction

ECLint is a tool for validating or fixing code that doesn't adhere to settings defined in .editorconfig. It also infers settings from existing code. See the EditorConfig Project for details about the .editorconfig file.

This version of ECLint runs on EditorConfig Core 0.15.x.

Installation

$ npm install [-g] eclint

Features

Command-Line Interface (CLI)
Check, fix or infer the following EditorConfig rules across one or more files:
TypeScript/JavaScript API
Gulp plugin

CLI

The command-line interface (CLI) for this project uses gitlike-cli to parse the eclint command, along with its check, fix and infer sub-commands. Internally, the command is sent to the API to do its magic.

Running eclint --help will provide the following help information:

$ eclint --help
Usage: eclint <command> [files...] [options]

Commands:
  check [files...]  Validate that file(s) adhere to .editorconfig settings
  fix   [files...]  Fix formatting errors that disobey .editorconfig settings
  infer [files...]  Infer .editorconfig settings from one or more files

Options:
  --help     Show help                                                 [boolean]
  --version  Show version number                                       [boolean]

Check

The eclint check sub-command allows you to validate that files adhere to their respective EditorConfig settings. Running eclint check --help will provide you the following help information:

$ eclint check --help
eclint check [files...]

Options:
  --help                          Show help                                                             [boolean]
  --version                       Show version number                                                   [boolean]
  --indent_style, -i              Indentation Style                                                     [choices: "tab", "space", undefined]
  --indent_size, -s               Indentation Size (in single-spaced characters)                        [number]
  --tab_width, -t                 Width of a single tabstop character                                   [number]
  --end_of_line, -e               Line ending file format (Unix, DOS, Mac)                              [choices: "lf", "crlf", "cr", undefined]
  --charset, -c                   File character encoding                                               [choices: "latin1", "utf-8", "utf-8-bom", "utf-16le", "utf-16be", undefined]
  --trim_trailing_whitespace, -w  Denotes whether whitespace is allowed at the end of lines             [boolean]
  --insert_final_newline, -n      Denotes whether file should end with a newline                        [boolean]
  --max_line_length, -m           Forces hard line wrapping after the amount of characters specified    [number]
  --block_comment_start           Block comments start with                                             [string]
  --block_comment                 Lines in block comment start with                                     [string]
  --block_comment_end             Block comments end with                                               [string]

Running this sub-command without any [options] will use each file's EditorConfig settings as the validation settings. In fact, you don't even need to pass-in any CLI [options] for this sub-command to work, but doing so will allow you to override the .editorconfig file settings in cases where you want more fine-grain control over the outcome.

Each CLI option has both short and long flag variations. As such, you can use --indent_size 2 or -i 2, whichever you prefer. Short flags may be combined into a single argument. For example, -swe 2 lf is the same as -s 2 -w -e lf.

The [<files>...] args allows you to pass-in one or more file paths or globs. You may, however, need to surround your glob expressions in quotes for it to work properly. Unfortunately, in bash, you can't add a negative glob with "!foo.js". Instead, you can put square brackets around the ! and eclint will take care of it. For example, "[!]foo.js".

The result of running eclint check * in this project's root, if there were issues, would look something like the following:

Z:\Documents\GitHub\eclint\README.md: Invalid indent style: space

If any errors are reported, the Node process will exit with a status code of 1, failing any builds or continuous integrations you may have setup. This is to help you enforce EditorConfig settings on your project or team. For Travis-CI, you can do this by adding the following before_script block to your .travis.yml file:

before_script:
  - npm install -g eclint
  - eclint check * "lib/**/*.js"

This is the same method this project is doing in its own .travis.yml file for reference.

Now should be a great time to segue into the fix sub-command.

Fix

<table> <tr> <td width="99"> <img src="https://github.com/jedmao/eclint/blob/master/images/warning.png?raw=true" alt="Warning, Stop!" width="72" height="65"> </td> <td> <strong style="display:table-cell">Warning! Fixing your files will change their contents. Ensure that your files are under version control and that you have committed your changes before attempting to fix any issues with them. You can also run the check command to know which files will change before you fix them.</strong> </td> </tr> </table>

The eclint fix sub-command allows you to fix files that don't adhere to their respective EditorConfig settings. Running eclint fix --help will provide you the following help information:

$ eclint fix --help
eclint fix   [files...]

Options:
  --help                          Show help                                                             [boolean]
  --version                       Show version number                                                   [boolean]
  --indent_style, -i              Indentation Style                                                     [choices: "tab", "space", undefined]
  --indent_size, -s               Indentation Size (in single-spaced characters)                        [number]
  --tab_width, -t                 Width of a single tabstop character                                   [number]
  --end_of_line, -e               Line ending file format (Unix, DOS, Mac)                              [choices: "lf", "crlf", "cr", undefined]
  --charset, -c                   File character encoding                                               [choices: "latin1", "utf-8", "utf-8-bom", "utf-16le", "utf-16be", undefined]
  --trim_trailing_whitespace, -w  Denotes whether whitespace is allowed at the end of lines             [boolean]
  --insert_final_newline, -n      Denotes whether file should end with a newline                        [boolean]
  --max_line_length, -m           Forces hard line wrapping after the amount of characters specified    [number]
  --block_comment_start           Block comments start with                                             [string]
  --block_comment                 Lines in block comment start with                                     [string]
  --block_comment_end             Block comments end with                                               [string]
  --dest, -d                      Destination folder to pipe source files                               [string]

You might notice this sub-command looks very similar to the check sub-command. It works essentially the same way; except, instead of validating files, it enforces the settings on each file by altering their contents. I'll let you read the check sub-command so I don't have to repeat myself.

One key difference you'll notice is an additional -d, --dest <folder> option. This option gives you control over where the result file tree will be written. Without this specified, the files will be overwritten in the source location by default.

Infer

The eclint infer sub-command allows you to infer what the EditorConfig settings should be for all files you specify. Running eclint infer --help will provide you the following help information:

$ eclint infer --help
eclint infer [files...]

Options:
  --help       Show help                                               [boolean]
  --version    Show version number                                     [boolean]
  --score, -s  Shows the tallied score for each setting                [boolean]
  --ini, -i    Exports file as ini file type                           [boolean]
  --root, -r   Adds root = true to your ini file, if any               [boolean]

This sub-command generates a report that reveals wha

Eclint

Install / Use

README