Modular TSLint configuration

Combine modules to get the right configuration for your project

Modular TSLint Configuration

Cross-Platform Compatibility Build Status


npm License

tslint-modular is a set of configuration presets for TSLint that’s broken-up into different modules that can be mixed-and-matched to match the needs of your project.

Each module defines rules that are meant to be reasonable defaults and best practices, but you can easily extend or override any of the rules to suit your needs.


Run the following npm command to install TSLint and tslint-modular as dev-dependencies of your project:

npm install tslint tslint-modular --save-dev


Configuration presets are designed to work with the extends feature of tslint.yaml files. You can learn more about configuration presets on the official TSLint website.

To use tslint-modular in your project, create a tslint.yaml file with the following contents:


  # These modules would be good for a library that runs in Node.js and web browsers
  - tslint-modular/best-practices
  - tslint-modular/style
  - tslint-modular/node
  - tslint-modular/browser

  # You can override or extend the rules here


tslint-modular includes the following modules. Mix-and-match them as applicable to your project.

tslint-modular/best-practices (source)

Contains rules that prevent accidental bugs, insecure code, and bad coding practices. You can use this module directly, or use any/all of its sub-modules.

tslint-modular/best-practices/bugs (source)

Prevents syntax that is likely to lead to accidental bugs or runtime errors. Examples include not duplicate variables, and using === instead of == for comparisons. Most of the rules in this file will raise an error if violated, but some less-severe ones will only raise warnings.

tslint-modular/best-practices/maintainability (source)

Helps you write code that is more maintainable over time and by multiple people. For example, limiting cyclomatic complexity and keeping files short.

tslint-modular/best-practices/security (source)

Helps enforce security best-practices such as avoiding the eval() statement and not calling the Function constructor.

tslint-modular/browser (source)

Bans bad practices for web-based code, such as the alert() statement and the jQuery global.

tslint-modular/node (source)

Discourages deprecated and outdated Node.js code, such as fs.exists(). It encourages using more modern syntax, such as the fs.promises API.

tslint-modular/style (source)

Contains code-styling and consistency rules. You can use this module directly, or use any/all of its sub-modules.

tslint-modular/style/comments (source)

Code-commenting rules, such as documenting all public members, using JSDoc format, and not duplicating type information in comments.

tslint-modular/style/conventions (source)

Enforces an opinionated set of conventions, such as using double-quotes and semi-colons.

tslint-modular/style/naming (source)

Encourages good JavaScript naming conventions, such as camel-case variables and capitialized classes.

tslint-modular/style/syntax (source)

Disallows outdated, nonstandard, and confusing syntax. Examples include labels, the comma operator, and parameter properties.

tslint-modular/style/whitespace (source)

Enforces opinionated whitespace rules, such as two-space indentation, opening braces on the same line, and type definition spacing.

tslint-modular/test (source)

Warns about describe.only() and it.only() calls that may have accidentally been left in your test code.

Note: We recommend that you create a separate tslint.yaml file in your test folder. That way, it can use different modules and rules than the rest of your codebase.

Big Thanks To

Thanks to these awesome companies for their support of Open Source developers ❤

Travis CI SauceLabs Coveralls