tslint-microsoft-contrib

tslint-microsoft-contrib

A set of TSLint rules used on some Microsoft projects.

Version 2.0.5

The project has been in use for at least several months on multiple projects. Please report any bugs or false positives you might find!

TSLint and corresponding tslint-microsoft-contrib version

TSLint version	tslint-microsoft-contrib version
>= 3.2.x	2.x
3.1.x	unsupported
3.0.x	unsupported
2.x	1.x

Installation

npm install tslint-microsoft-contrib

Alternately, you can download the files directly from GitHub:

• Latest Development Version
• 2.0.3
• 2.0.2
• 2.0.1
• 2.0.0
• 1.0.0
• 0.0.4

Configuration

Configure your Grunt build task

Add the new rulesDirectory to your tslint task:

grunt.initConfig({
  tslint: {
    options: {
      rulesDirectory: 'node_modules/tslint-microsoft-contrib',
      configuration: grunt.file.readJSON("tslint.json")
    },
    files: {
      src: ['src/file1.ts', 'src/file2.ts']
    }
  }
})

The tslint.json file does not change format when using this package. Just add our rule definitions to your existing tslint.json file.

A sample configuration file with all options is available here: tslint.json

Supported Rules

Rule Name	Description	Since
chai-vague-errors	Avoid Chai assertions that result in vague errors. For example, asserting expect(something).to.be.true will result in the failure message "Expected true received false". This is a vague error message that does not reveal the underlying problem. It is especially vague in TypeScript because stack trace line numbers often do not match the source code. A better pattern to follow is the xUnit Patterns Assertion Message pattern. The previous code sample could be better written as expect(something).to.equal(true, 'expected something to have occurred');	1.0
export-name	The name of the exported module must match the filename of the source file. This is case-sensitive but ignores file extension. Since version 1.0, this rule takes a list of regular expressions as a parameter. Any export name matching that regular expression will be ignored. For example, to allow an exported name like myChartOptions, then configure the rule like this: "export-name": [true, "myChartOptionsg"]	0.0.3
import-name	The name of the imported module must match the name of the thing being imported. For example, it is valid to name imported modules the same as the module name: import Service = require('x/y/z/Service') and import Service from 'x/y/z/Service'. But it is invalid to change the name being imported, such as: import MyCoolService = require('x/y/z/Service') and import MyCoolService from 'x/y/z/Service'.	2.0.5
jquery-deferred-must-complete	When a JQuery Deferred instance is created, then either reject() or resolve() must be called on it within all code branches in the scope. For more examples see the feature request.	1.0
max-func-body-length	Avoid long functions. The line count of a function body must not exceed the value configured within this rule's options. You can setup a general max function body length applied for every function/method/arrow function e.g. [true, 30] or set different maximum length for every type e.g. [true, { "func-body-length": 10 , "arrow-body-length": 5, "method-body-length": 15, "ctor-body-length": 5 }]. To specify a function name whose parameters you can ignore for this rule, pass a regular expression as a string(this can be useful for Mocha users to ignore the describe() function)	2.0.3
missing-jsdoc	All files must have a top level JSDoc comment. A JSDoc comment starts with /** (not one more or one less asterisk) and a JSDoc at the 'top-level' appears without leading spaces. Trailing spaces are acceptable but not recommended.	1.0
missing-optional-annotation	A parameter that follows one or more parameters marked as optional is not itself marked optional	0.0.1
mocha-avoid-only	Do not invoke Mocha's describe.only or it.only functions. These functions are useful ways to run a single unit test or a single test case during your build, but please be careful to not push these methods calls to your version control repositiory because it will turn off any of the other tests.	1.0
no-backbone-get-set-outside-model	Avoid using model.get('x') and model.set('x', value) Backbone accessors outside of the owning model. This breaks type safety and you should define getters and setters for your attributes instead.	1.0
no-banned-terms	Do not use banned terms: caller, callee, eval, arguments. These terms refer to functions or properties that should not be used, so it is best practice to simply avoid them.	0.0.1
no-constant-condition	Do not use constant expressions in conditions. Similar to the ESLint no-constant-condition rule	1.0
no-control-regex	Do not use control characters in regular expressions . Similar to the ESLint no-control-regex rule	1.0
no-cookies	Do not use cookies	0.0.1
no-delete-expression	Do not delete expressions. Only properties should be deleted	0.0.2
no-disable-auto-sanitization	Do not disable auto-sanitization of HTML because this opens up your page to an XSS attack. Specifically, do not use the execUnsafeLocalFunction or setInnerHTMLUnsafe functions.	0.0.1
no-document-domain	Do not write to document.domain. Scripts setting document.domain to any value should be validated to ensure that the value is on a list of allowed sites. Also, if your site deals with PII in any way then document.domain must not be set to a top-level domain (for example, live.com) but only to an appropriate subdomain (for example, billing.live.com). If you are absolutely sure that you want to set document.domain then add a tslint suppression comment for the line. For more information see the Phase 4 Verification page of the Microsoft SDL	2.0.3
no-document-write	Do not use document.write	0.0.1
no-duplicate-case	Do not use duplicate case labels in switch statements. Similar to the ESLint no-duplicate-case rule	1.0
no-duplicate-parameter-names	Do not write functions or methods with duplicate parameter names	0.0.1
no-empty-interfaces	Do not use empty interfaces. They are compile-time only artifacts and they serve no useful purpose	1.0
no-exec-script	Do not use the execScript functions	0.0.1
no-for-in	Avoid use of for-in statements. They can be replaced by Object.keys	1.0
no-function-constructor-with-string-args	Do not use the version of the Function constructor that accepts a string argument to define the body of the function	0.0.1
no-function-expression	Do not use function expressions; use arrow functions (lambdas) instead. In general, lambdas are simpler to use and avoid the confusion about what the 'this' references points to. Function expressions that contain a 'this' reference are allowed and will not create a failure.	1.0
no-http-string	Do not use strings that start with 'http:'. URL strings should start with 'https:'. Http strings can be a security problem and indicator that your software may suffer from cookie-stealing attacks. Since version 1.0, this rule takes a list of regular expressions as a parameter. Any string matching that regular expression will be ignored. For example, to allow http connections to example.com and examples.com, configure your rule like this: "no-http-string": [true, "http://www.example.com/?.*", "http://www.examples.com/?.*"\]	0.0.3
no-increment-decrement	Avoid use of increment and decrement operators particularly as part of complicated expressions	0.0.1
no-inner-html	Do not write values to innerHTML, outerHTML, or set HTML using the JQuery html() function. Writing values to innerHTML can expose your website to XSS injection attacks. All strings must be escaped before being rendered to the page.	2.0.4
no-invalid-regexp	Do not use invalid regular expression strings in the RegExp constructor. Similar to the ESLint no-invalid-regexp rule	1.0
no-missing-visibility-modifiers	Class members (both fields and methods) should have visibility modifiers specified. THe Principle of Least Visibility guides us to prefer private methods and fields when possible. If a developer forgets to add a modifier then TypeScript assumes the element should be public, which is the wrong default choice.	1.0
no-multiline-string	Do not declare multiline strings	0.0.1
no-multiple-var-decl	Deprecated - This rule is now part of the base TSLint product as the rule named 'one-variable-per-declaration'. Do not use comma separated variable declarations	1.0
no-octal-literal	Do not use octal literals or escaped octal sequences	0.0.1
no-regex-spaces	Do not use multiple spaces in a regular expression literal. Similar to the ESLint no-regex-spaces rule	1.0
no-relative-imports	Do not use relative paths when importing external modules or ES6 import declarations.	2.0.5
no-reserved-keywords	Do not use reserved keywords as names of local variables, fields, functions, or other identifiers.	0.0.1
no-sparse-arrays	Do not use sparse arrays. Sparse arrays contain empty slots, most frequently due to multiple commas being used in an array literal. Based on the ESLint no-sparse-arrays rule	1.0
no-stateless-class	A stateless class represents a failure in the object oriented design of the system. A class without state is better modeled as a module or given some state. A stateless class is defined as a class with only static members and no parent class.	2.0.4
no-string-based-set-immediate	Do not use the version of setImmediate that accepts code as a string argument. However, it is acceptable to use the version of setImmediate where a direct reference to a function is provided as the callback argument	0.0.1
no-string-based-set-interval	Do not use the version of setInterval that accepts code as a string argument. However, it is acceptable to use the version of setInterval where a direct reference to a function is provided as the callback argument	0.0.1
no-string-based-set-timeout	Do not use the version of setTimeout that accepts code as a string argument. However, it is acceptable to use the version of setTimeout where a direct reference to a function is provided as the callback argument	0.0.1
no-unexternalized-strings	Ensures that double quoted strings are passed to a localize call to provide proper strings for different locales. The rule can be configured using an object literal as document in the feature request	2.0.1
no-unnecessary-bind	Do not bind 'this' as the context for a function literal or lambda expression. If you bind 'this' as the context to a function literal, then you should just use a lambda without the bind. If you bind 'this' as the context to a lambda, then you can remove the bind call because 'this' is already the context for lambdas. Works for Underscore methods as well.	1.0
no-unnecessary-local-variable	Do not declare a variable only to return it from the function on the next line. It is always less code to simply return the expression that initializes the variable.	2.0.4
no-unnecessary-override	Do not write a method that only calls super() on the parent method with the same arguments. You can safely remove methods like this and Javascript will correctly dispatch the method to the parent object.	2.0.4
no-unnecessary-semicolons	Remove unnecessary semicolons	0.0.1
no-unused-imports	Remove unused imports	0.0.1
no-with-statement	Do not use with statements. Assign the item to a new variable instead	0.0.1
prefer-array-literal	Use array literal syntax when declaring or instantiating array types. For example, prefer the Javascript form of string[] to the TypeScript form Array. Prefer '[]' to 'new Array()'. Prefer '[4, 5]' to 'new Array(4, 5)'. Prefer '[undefined, undefined]' to 'new Array(4)'.	1.0
prefer-type-cast	Prefer the tradition type casts instead of the new 'as-cast' syntax. For example, prefer 'myVariable' instead of 'myVariable as string'. Rule ignores any file ending in .tsx. If you prefer the opposite and want to see the 'as type' casts, then enable the tslint rule named 'no-angle-bracket-type-assertion'	2.0.4
promise-must-complete	When a Promise instance is created, then either the reject() or resolve() parameter must be called on it within all code branches in the scope. For more examples see the feature request.	1.0
react-no-dangerous-html	Do not use React's dangerouslySetInnerHTML API. This rule finds usages of the dangerouslySetInnerHTML API (but not any JSX references). For more info see the react-no-dangerous-html Rule wiki page.	0.0.2
use-isnan	Deprecated - This rule is now part of the base TSLint product. Ensures that you use the isNaN() function to check for NaN references instead of a comparison to the NaN constant. Similar to the use-isnan ESLint rule.	1.0
use-named-parameter	Do not reference the arguments object by numerical index; instead, use a named parameter. This rule is similar to JSLint's Use a named parameter rule.	0.0.3
valid-typeof	Ensures that the results of typeof are compared against a valid string. This rule aims to prevent errors from likely typos by ensuring that when the result of a typeof operation is compared against a string, that the string is a valid value. Similar to the valid-typeof ESLint rule.	1.0

Development

To develop tslint-microsoft-contrib simply clone the repository, install dependencies and run grunt:

git config --global core.autocrlf input
git config --global core.eol lf
git clone [e-mail]:Microsoft/tslint-microsoft-contrib.git
cd tslint-microsoft-contrib
npm install
grunt all
grunt create-rule --rule-name=no-something-or-other

Debug code

If command fails because of file access permissions, prefix it with sudo.

npm install -g node-inspector

Then run:

node-debug grunt mochaTest

The node-debug command will load Node Inspector in your default browser (works in Chrome and Opera only).

Set a breakpoint somewhere in your code and resume execution. Your breakpoint should be hit.

Creating a new Release

Refer to the Releases Wiki Page