By default, configuration is loaded from tslint.json, if it exists in the current path, or the user's home directory, in that order.

tslint accepts the following commandline options:

-f, --file:
The location of the TypeScript file that you wish to lint. This
option is required. Muliptle files are processed consecutively.
-c, --config:
The location of the configuration file that tslint will use to
determine which rules are activated and what options to provide
to the rules. If no option is specified, the config file named
tslint.json is used, so long as it exists in the path.
The format of the file is { rules: { /* rules list */ } },
where /* rules list */ is a key: value comma-seperated list of
rulename: rule-options pairs. Rule-options can be either a
boolean true/false value denoting whether the rule is used or not,
or a list [boolean, ...] where the boolean provides the same role
as in the non-list case, and the rest of the list are options passed
to the rule that will determine what it checks for (such as number
of characters for the max-line-length rule, or what functions to ban
for the ban rule).
-o, --out:
A filename to output the results to. By default, tslint outputs to
stdout, which is usually the console where you're running it from.
-r, --rules-dir:
An additional rules directory, for user-created rules.
tslint will always check its default rules directory, in
node_modules/tslint/build/rules, before checking the user-provided
rules directory, so rules in the user-provided rules directory
with the same name as the base rules will not be loaded.
-s, --formatters-dir:
An additional formatters directory, for user-created formatters.
Formatters are files that will format the tslint output, before
writing it to stdout or the file passed in --out. The default
directory, node_modules/tslint/build/formatters, will always be
checked first, so user-created formatters with the same names
as the base formatters will not be loaded.
-t, --format:
The formatter to use to format the results of the linter before
outputting it to stdout or the file passed in --out. The core
formatters are prose (human readable) and json (machine readable),
and prose is the default if this option is not used. Additional
formatters can be added and used if the --formatters-dir option
is set.
--help:
Prints this help message.

typedef-whitespace enforces spacing whitespace for type definitions. Each rule option requires a value of "space" or "nospace"
to require a space or no space before the type specifier's colon. Rule options:

"call-signature" checks return type of functions

"index-signature" checks index type specifier of indexers

"parameter" checks function parameters

"property-declaration" checks object property declarations

"variable-declaration" checks variable declaration

use-strict enforces ECMAScript 5's strict mode

check-module checks that all top-level modules are using strict mode

check-function checks that all top-level functions are using strict mode

You can enable/disable TSLint or a subset of rules within a file with the following comment rule flags:

/* tslint:disable */ - Disable all rules for the rest of the file

/* tslint:enable */ - Enable all rules for the rest of the file

/* tslint:disable:rule1 rule2 rule3... */ - Disable the listed rules for the rest of the file

/* tslint:enable:rule1 rule2 rule3... */ - Enable the listed rules for the rest of the file

Rules flags enable or disable rules as they are parsed. A rule is enabled or disabled until a later directive commands otherwise. Disabling an already disabled rule or enabling an already enabled rule has no effect.

For example, imagine the directive /* tslint:disable */ on the first line of a file, /* tslint:enable:ban class-name */ on the 10th line and /* tslint:enable */ on the 20th. No rules will be checked between the 1st and 10th lines, only the ban and class-name rules will be checked between the 10th and 20th, and all rules will be checked for the remainder of the file.

TSLint ships with a set of core rules that can be configured. However, users are also allowed to write their own rules, which allows them to enforce specific behavior not covered by the core of TSLint. TSLint's internal rules are itself written to be pluggable, so adding a new rule is as simple as creating a new rule file named by convention. New rules can be written in either TypeScript or Javascript; if written in TypeScript, the code must be compiled to Javascript before invoking TSLint.

Rule names are always camel-cased and must contain the suffix Rule. Let us take the example of how to write a new rule to forbid all import statements (you know, for science). Let us name the rule file noImportsRule.ts. Rules can be referenced in tslint.json in their dasherized forms, so "no-imports": true would turn on the rule.

Now, let us first write the rule in TypeScript. At the top, we reference TSLint's definition file. The exported class name must always be named Rule and extend from Lint.Rules.AbstractRule.

Given a walker, TypeScript's parser visits the AST using the visitor pattern. So the rule walkers only need to override the appropriate visitor methods to enforce its checks. For reference, the base walker can be found in syntaxWalker.ts.

We still need to hook up this new rule to TSLint. First make sure to compile noImportsRule.ts: tsc -m commonjs --noImplicitAny noImportsRule.ts tslint.d.ts. Then, if using the CLI, provide the directory that contains this rule as an option to --rules-dir. If using TSLint as a library or via grunt-tslint, the options hash must contain "rulesDirectory": "...". If you run the linter, you'll see that we have now successfully banned all import statements via TSLint!

Just like rules, additional formatters can also be supplied to TSLint via --formatters-dir on the CLI or formattersDirectory option on the library or grunt-tslint. Writing a new formatter is simpler than writing a new rule, as shown in the JSON formatter's code.