The tslint npm package is a static analysis tool that checks TypeScript code for readability, maintainability, and functionality errors. It is widely used to enforce a consistent code style by checking the code against a set of linting rules.
Linting TypeScript Files
This feature allows you to lint TypeScript files by specifying a configuration file and a pattern to match files. The command will process all TypeScript files in the 'src' directory and its subdirectories.
tslint -c tslint.json 'src/**/*.ts'Fixing Linting Errors Automatically
This feature automatically fixes linting errors that can be corrected without human intervention. It is useful for fixing simple issues like whitespace or semicolon usage.
tslint --fix -c tslint.json 'src/**/*.ts'Custom Rules
This feature allows you to use custom linting rules in addition to the predefined rules. You can specify a directory containing custom rule definitions to be applied to your code.
tslint -c tslint.json 'src/**/*.ts' --rules-dir custom_rulesESLint is a popular linting tool for JavaScript and TypeScript. It is highly configurable and extendable, with a large ecosystem of plugins. ESLint has effectively replaced TSLint as the preferred linter for TypeScript after TSLint's deprecation.
Prettier is an opinionated code formatter that supports many languages, including TypeScript. While it does not perform static code analysis, it formats code to a consistent style. Prettier can be used alongside linters like ESLint.
Stylelint is a modern linter that helps you avoid errors and enforce conventions in your stylesheets. Although it is primarily used for CSS, it can be used in conjunction with PostCSS to lint SCSS, Sass, Less, and other CSS-like languages.
A linter for the TypeScript language.
ban bans the use of specific functions. Options are ["object", "function"] pairs that ban the use of object.function()class-name enforces PascalCased class and interface names.comment-format enforces rules for single-line comments. Rule options:
"check-space" enforces the rule that all single-line comments must begin with a space, as in // comment
/// are also allowed, for things such as ///"check-lowercase" enforces the rule that the first non-whitespace character of a comment must be lowercase, if applicablecurly enforces braces for if/for/do/while statements.eofline enforces the file to end with a newline.forin enforces a for ... in statement to be filtered with an if statement.*indent enforces consistent indentation levels (currently disabled).interface-name enforces the rule that interface names must begin with a capital 'I'jsdoc-format enforces basic format rules for jsdoc comments -- comments starting with /**
label-position enforces labels only on sensible statements.label-undefined checks that labels are defined before usage.max-line-length sets the maximum length of a line.no-arg disallows access to arguments.callee.no-bitwise disallows bitwise operators.no-console disallows access to the specified functions on console. Rule options are functions to ban on the console variable.no-consecutive-blank-lines disallows having more than one blank line in a row in a fileno-construct disallows access to the constructors of String, Number, and Boolean.no-debugger disallows debugger statements.no-duplicate-key disallows duplicate keys in object literals.no-duplicate-variable disallows duplicate variable declarations.no-empty disallows empty blocks.no-eval disallows eval function invocations.no-string-literal disallows object access via string literals.no-trailing-comma disallows trailing comma within object literals.no-trailing-whitespace disallows trailing whitespace at the end of a line.no-unused-variable disallows unused imports, variables, functions and private class members.no-unreachable disallows unreachable code after break, catch, throw, and return statements.no-use-before-declare disallows usage of variables before their declaration.one-line enforces the specified tokens to be on the same line as the expression preceding it. Rule options:
"check-catch" checks that catch is on the same line as the closing brace for try"check-else" checks that else is on the same line as the closing brace for if"check-open-brace" checks that an open brace falls on the same line as its preceding expression."check-whitespace" checks preceding whitespace for the specified tokens.quotemark enforces consistent single or double quoted string literals.radix enforces the radix parameter of parseIntsemicolon enforces semicolons at the end of every statement.triple-equals enforces === and !== in favor of == and !=.typedef enforces type definitions to exist. Rule options:
"callSignature" checks return type of functions"catchClause" checks type in exception catch blocks"indexSignature" checks index type specifier of indexers"parameter" checks type specifier of parameters"propertySignature" checks return types of interface properties"variableDeclarator" checks variable declarationstypedef-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:
"callSignature" checks return type of functions"catchClause" checks type in exception catch blocks"indexSignature" checks index type specifier of indexersuse-strict enforces ECMAScript 5's strict mode
check-module checks that all top-level modules are using strict modecheck-function checks that all top-level functions are using strict modevariable-name allows only camelCased or UPPER_CASED variable names. Rule options:
"allow-leading-underscore" allows underscores at the beginnning.whitespace enforces spacing whitespace. Rule options:
"check-branch" checks branching statements (if/else/for/while) are followed by whitespace"check-decl"checks that variable declarations have whitespace around the equals token"check-operator" checks for whitespace around operator tokens"check-separator" checks for whitespace after separator tokens (,/;)"check-type" checks for whitespace before a variable type specificationYou 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 fileRules 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.
sudo npm install tslint -g
npm install tslint
Please first ensure that the TypeScript source files compile correctly.
usage: tslint
Options:
-c, --config configuration file
-f, --file file to lint [required]
-o, --out output file
-r, --rules-dir rules directory
-s, --formatters-dir formatters directory
-t, --format output format (prose, json) [default: "prose"]
By default, configuration is loaded from tslint.json, if it exists in the current path.
tslint accepts the following commandline options:
-f, --file:
The location of the TypeScript file that you wish to lint. This
option is required.
-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.
var options = {
formatter: "json",
configuration: configuration,
rulesDirectory: "customRules/",
formattersDirectory: "customFormatters/"
};
var Linter = require("tslint");
var ll = new Linter(fileName, contents, options);
var result = ll.lint();
git clone git@github.com:palantir/tslint.git
npm install
grunt
v0.4.3
no-unused-variableno-trailing-commano-use-before-declare--version in CLIverbose formatterno-empty allows constructors with member declaration parameters--helpmax-line-length allows CRLF endingsFAQs
An extensible static analysis linter for the TypeScript language
The npm package tslint receives a total of 1,329,058 weekly downloads. As such, tslint popularity was classified as popular.
We found that tslint demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team uncovered a malicious Python package typosquatting the popular 'fabric' SSH library, silently exfiltrating AWS credentials from unsuspecting developers.
Security News
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.