Package Health Score

61 / 100

security
No known security issues
popularity
Popular
maintenance
Inactive
community
Active

Explore Similar Packages

Security

No known security issues

All security vulnerabilities belong to production dependencies of direct and indirect packages.

Security and license risk for significant versions

Version				Vulnerabilities	License Risk
6.2.0	\|	05/2019		0 C 0 H 0 M 0 L	0 H 0 M 0 L
6.1.1	\|	04/2019		0 C 0 H 0 M 0 L	0 H 0 M 0 L
5.2.1	\|	08/2018	Popular	0 C 0 H 0 M 0 L	0 H 0 M 0 L
4.0.1	\|	03/2017		0 C 0 H 0 M 0 L	0 H 0 M 0 L
2.0.14	\|	12/2016		0 C 0 H 0 M 0 L	0 H 0 M 0 L

License

MIT

Security Policy

Is your project affected by vulnerabilities?

Scan your projects for vulnerabilities. Fix quickly with automated fixes. Get started with Snyk for free.

Get started free

Popularity

Popular

Weekly Downloads (112,161)

GitHub Stars: 701
Forks: 198
Contributors: 100

Direct Usage Popularity

The npm package tslint-microsoft-contrib receives a total of 112,161 downloads a week. As such, we scored tslint-microsoft-contrib popularity level to be Popular.

Based on project statistics from the GitHub repository for the npm package tslint-microsoft-contrib, we found that it has been starred 701 times.

Downloads are calculated as moving averages for a period of the last 12 months, excluding weekends and known missing data points.

Community

Active

Readme.md: Yes
Contributing.md: Yes
Code of Conduct: Yes
Contributors: 100
Funding: No

With more than 10 contributors for the tslint-microsoft-contrib repository, this is possibly a sign for a growing and inviting community.

Embed Package Health Score Badge

Maintenance

Inactive

deprecated

Commit Frequency

No Recent Commits

Open Issues: 0
Open PR: 0
Last Release: 6 years ago
Last Commit: 4 years ago

Further analysis of the maintenance status of tslint-microsoft-contrib based on released npm versions cadence, the repository activity, and other data points determined that its maintenance is Inactive.

An important project maintenance signal to consider for tslint-microsoft-contrib is that it hasn't seen any new versions released to npm in the past 12 months, and could be considered as a discontinued project, or that which receives low attention from its maintainers.

In the past month we didn't find any pull request activity or change in issues status has been detected for the GitHub repository.

Keep your project healthy

Check your package.json

Ensure all the packages you're using are healthy and well-maintained

Snyk Vulnerability Scanner

Get health score & security insights directly in your IDE

Package

Node.js Compatibility: not defined

Age: 9 years
Dependencies: 1 Direct
Versions: 38
Install Size: 658 kB
Dist-tags: 2
# of Files: 180
Maintainers: 5
TS Typings: No

tslint-microsoft-contrib has more than a single and default latest tag published for the npm package. This means, there may be other tags available for this package, such as next to indicate future releases, or stable to indicate stable releases.

Readme

tslint-microsoft-contrib

A set of TSLint rules used on some Microsoft projects.

Installation

npm install tslint-microsoft-contrib --save-dev

TSLint and corresponding tslint-microsoft-contrib version

TSLint version	tslint-microsoft-contrib version
>= 5.x	5.x and 6.x (supporting TypeScript 2.3.x, >=2.4, 3.x)
>= 4.x	4.x (supporting TypeScript 2.1.x)
>= 3.2.x	2.x
3.1.x	unsupported
3.0.x	unsupported
2.x	1.x

Configuration

Add "node_modules/tslint-microsoft-contrib" under your "rulesDirectory" configuration to inform TSLint it should look under this package for additional rules in your tslint.json:

{
    "rulesDirectory": ["node_modules/tslint-microsoft-contrib"],
    "rules": {
        // ...
    }
}

Which Rules Should I Turn On?

There certainly are a lot of options!

If you extend from one of the following configurations, rulesDirectory will have node_modules/tslint-microsoft-contrib included for you.

> Please note, some of the default ruleset rules require the --project TSLint option.

Latest

To run with the latest and greatest rules (latest.json), extend from tslint-microsoft-contrib/latest:

{
    "extends": ["tslint-microsoft-contrib/latest"]
    // ...
}

These rules will not be added to in patch releases, but will be in minor releases.

Legacy

The old "recommended" ruleset that ships by extending tslint-microsoft-contrib itself contains a list of rules that includes core TSLint rules.

To start, you can enable our recommended defaults (recommended.json) by adding just "tslint-microsoft-contrib" under "extends" in your tslint.json:

{
    "extends": ["tslint-microsoft-contrib"]
    // ...
}

This ruleset is considered legacy; it is generally preferable to extend from the 'recommended' or 'latest' rulesets. We recommend you instead explicitly include tslint:recommended, tslint:latest, or tslint:all in your tslint.json rather than enable core rules through this configuration.

In the next major version of TSLint, this will instead be an alias for "tslint-microsoft-contrib/recommended".

Overriding Configurations

You can disable rules you don't find useful.

If you rely on version ranges in your dependencies then you may find that new rules being added to the product create violations and fail your build. We recommend you specify exact versions of lint libraries, including tslint-microsoft-contrib, in your package.json.

Supported Rules

Rule Name	Description	Since
`chai-prefer-contains-to-index-of`	Avoid Chai assertions that invoke indexOf and compare for a -1 result. It is better to use the chai .contain() assertion API instead because the failure message will be clearer if the test fails.	2.0.10
`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
`detect-child-process`	Detects usages of child_process and especially child_process.exec() with a non-literal first argument. It is dangerous to pass a string constructed at runtime as the first argument to the `child_process.exec()`. `child_process.exec(cmd)` runs `cmd` as a shell command which could allow an attacker to execute malicious code injected into `cmd`. Instead of `child_process.exec(cmd)` you should use `child_process.spawn(cmd)` or specify the command as a literal, e.g. `child_process.exec('ls')`.	6.2.0-beta
`export-name`	The name of the exported module must match the filename of the source file. This is case-insensitive by default but ignores file extension. It can be configured to be case-insensitive or to allow names matching a regex. For example, to allow names that differ only in case and an exported name like myChartOptions, then configure the rule like this: `"export-name": [true, { "ignore-case": true, "allow": ["myChartOptions"] }]`. You can also just give a list of allowed names, like `"export-name": [true, "myChartOptions"]`.	0.0.3
`function-name`	Applies a naming convention to function names and method names. You can configure the naming convention by passing parameters. Please note, the private-method-regex does take precedence over the static-method-regex, so a private static method must match the private-method-regex. The default values are: `[ true, { "method-regex": "^[a-z][\\w\\d]+$", "private-method-regex": "^[a-z][\\w\\d]+$", "protected-method-regex": "^[a-z][\\w\\d]+$", "static-method-regex": "^[A-Z_\\d]+$", "function-regex": "^[a-z][\\w\\d]+$" } ]` This rule has some overlap with the [tslint variable-name rule](https://palantir.github.io/tslint/rules/variable-name/); however, the rule here is more configurable.	2.0.7, 2.0.14
`import-name`	The name of the imported module must match the name of the thing being imported. For special characters (`-`, `.`, `_`) remove them and make the following character uppercase. 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'`. When containing special characters such as `import $$ from 'my-awesome_library';` the corresponding configuration would look like `'import-name': [true, { 'myAwesomeLibrary': '$$' }]`. Since version 2.0.9 it is possible to configure this rule with a list of exceptions. For example, to allow `underscore` to be imported as `_`, add this configuration: `'import-name': [ true, { 'underscore': '_' }]`	2.0.5
`informative-docs`	Enforces that comments do more than just reiterate names of objects. Either be informative with comments or don't include a comment. You can override the default list of "useless" words ignored by the comment checker like `"informative-docs": [true, { "useless-words": ["a", "an", "the", "text" ] } ]`. You can indicate words as synonyms (aliases) of each other like `"informative-docs": [true, { "aliases": { text: ["emoji", "smiley"] } ]`.	6.0.0-beta
`insecure-random`	Do not use insecure sources for random bytes. Use a secure random number generator instead. Bans all uses of `Math.random` and `crypto.pseudoRandomBytes`. Better alternatives are `crypto.randomBytes` and `window.crypto.getRandomValues`. References: CWE 330 MDN Math.random `Node.js crypto.randomBytes()` `window.crypto.getRandomValues()`	2.0.11
`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 set up 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 , "func-expression-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). Since version 2.0.9, you can also ignore single- and multi-line comments from the total function length, eg. `[true, { "ignore-comments": true }].`	2.0.3
`missing-jsdoc`	Deprecated - This rule can be replaced with TSLint's `file-header` rule. All files must have a top level [JSDoc](https://usejsdoc.org/) 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`	Deprecated - This rule is now enforced by the TypeScript compiler. 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`, `it.only`, or `context.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 repository because it will turn off any of the other tests.	1.0
`mocha-no-side-effect-code`	All test logic in a Mocha test case should be within Mocha lifecycle method and not defined statically to execute when the module loads. Put all assignments and initialization statements in a `before()`, `beforeEach()`, `beforeAll()`, `after()`, `afterEach()`, `afterAll()`, or `it()` function. Code executed outside of these lifecycle methods can throw exceptions before the test runner is initialized and can result in errors or even test runner crashes. This rule can be configured with a regex to ignore certain initializations. For example, to ignore any calls to `RestDataFactory` configure the rule with: `[true, { ignore: '^RestDataFactory\\..*' }]`	2.0.10
`mocha-unneeded-done`	A function declares a MochaDone parameter but only resolves it synchronously in the main function. The MochaDone parameter can be safely removed from the parameter list.	2.0.10
`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](https://eslint.org/docs/rules/no-constant-condition) rule. Since version 2.0.14, this rule accepts a parameter called `checkLoops` which defaults to true. If set to false then loops are not checked for conditionals. For example, disable loop checking with `[ true, { 'checkLoops': false } ]`.	1.0, 2.0.14
`no-control-regex`	Do not use control characters in regular expressions . Similar to the [ESLint no-control-regex](https://eslint.org/docs/rules/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](https://msdn.microsoft.com/en-us/library/cc307418.aspx).	2.0.3
`no-document-write`	Do not use document.write	0.0.1
`no-duplicate-case`	Deprecated - This rule can be replaced with TSLint's no-duplicate-switch-case. Do not use duplicate case labels in switch statements. Similar to the ESLint no-duplicate-case rule.	1.0
`no-duplicate-parameter-names`	Deprecated - This rule is now enforced by the TypeScript compiler. Do not write functions or methods with duplicate parameter names.	0.0.1
`no-empty-interfaces`	Deprecated - This rule can be replaced with TSLint's no-empty-interface. Do not use empty interfaces. They are compile-time only artifacts and they serve no useful purpose.	1.0
`no-empty-line-after-opening-brace`	Avoid an empty line after an opening brace.	2.0.6
`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`	Deprecated - This rule is in the TSLint product as `function-constructor`. 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 'https:'. 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, "https://www.example.com/?.", "https://www.examples.com/?."]`.	0.0.3
`no-increment-decrement`	Deprecated - This rule is in the TSLint product as `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-jquery-raw-elements`	Do not create HTML elements using JQuery and string concatenation. It is error prone and can hide subtle defects. Instead use the JQuery element API.	2.0.8
`no-missing-visibility-modifiers`	Deprecated - This rule is in the TSLint product as `member-access`. 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. The advantages of removing all relative paths from imports is that: The import name will be consistent across all files and subdirectories so searching for usages is much easier. Moving source files to different folders will not require you to edit your import statements. 3) It will be possible to copy and paste import lines between files regardless of the file location. 4) version control diffs will be simplified by having overall fewer edits to the import lines. Option `allow-siblings` can be passed to allow relative imports for files in the same or nested folders. Note: we don't often recommend this rule. See #435 for discussion.	2.0.5
`no-reserved-keywords`	Deprecated - This rule can be replaced with TSLint's variable-name. Do not use reserved keywords as names of local variables, fields, functions, or other identifiers. Since version 2.0.9 this rule accepts a parameter called `allow-quoted-properties`. If true, interface properties in quotes will be ignored. This can be a useful way to avoid verbose suppress-warning comments for generated d.ts files. This rule has some overlap with the tslint variable-name rule; however, the rule here finds more keywords and more usages.	0.0.1, 2.0.9
`no-single-line-block-comment`	Avoid single line block comments and use single line comments instead. Block comments do not nest properly and have no advantages over normal single-line comments.	2.0.10
`no-stateless-class`	Deprecated - This rule can be replaced with TSLint's no-unnecessary-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-suspicious-comment`	Do not use suspicious comments, such as BUG, HACK, FIXME, LATER, LATER2, TODO. We recommend that you run this rule before each release as a quality checkpoint. Reference: CWE-546 Suspicious Comment.	2.0.11
`no-typeof-undefined`	Do not use the idiom `typeof x === 'undefined'`. You can safely use the simpler `x === undefined` or perhaps `x == null` if you want to check for either null or undefined.	2.0.8
`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 documented in the feature request.	2.0.1
`no-unnecessary-bind`	Deprecated - This rule is in the TSLint product as `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-field-initialization`	Do not unnecessarily initialize the fields of a class to values they already have. For example, there is no need to explicitly set a field to `undefined` in the field's initialization or in the class' constructor. Also, if a field is initialized to a constant value (null, a string, a boolean, or some number) then there is no need to reassign the field to this value within the class constructor.	2.0.9
`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-unsupported-browser-code`	Avoid writing browser-specific code for unsupported browser versions. Browser versions are specified in the rule configuration options, eg: `[true, [ "IE 11", "Firefox > 40", "Chrome >= 45" ] ]`. Browser-specific blocks of code can then be designated with a single-line comment, like so: `// Browser specific: IE 10`, or with a jsdoc like this: `@browserspecific chrome 40`.	2.0.10
`no-useless-files`	Avoid keeping files around that only contain commented out code, are completely empty, or only contain whitespace characters.	4.0.2
`no-var-self`	Deprecated - This rule can be replaced with TSLint's no-this-assignment. Do not use `var self = this`; instead, manage scope with arrow functions/lambdas. Self variables are a common practice in JavaScript but can be avoided in TypeScript. By default the rule bans any assignments of the `this` reference. If you want to enforce a naming convention or allow some usages then configure the rule with a regex. By default the rule is configured with `(?!)` which matches nothing. You can pass `^self$` to allow variables named self or pass `^(?!self$)` to allow anything other than self, for example.	2.0.8
`no-with-statement`	Do not use `with` statements. Assign the item to a new variable instead.	0.0.1
`non-literal-fs-path`	Detect `fs` function calls with a non literal filepath. For security reasons, it may be best to only pass string literals as filesystem paths. Otherwise, it may be possible for an attacker to read and write arbitrary files on your system through path traversal attacks.	6.0.0-beta
`non-literal-require`	Detect `require()` function calls for something that is not a string literal. For security reasons, it may be best to only `require()` string literals. Otherwise, it may be possible for an attacker to somehow change the value and download arbitrary Javascript into your page.	2.0.14
`possible-timing-attack`	Avoid timing attacks by not making direct string comparisons to sensitive data. Do not compare against variables named password, secret, api, apiKey, token, auth, pass, or hash. For more info see [Using Node.js Event Loop for Timing Attacks](https://snyk.io/blog/node-js-timing-attack-ccc-ctf).	2.0.11
`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<string>`. Prefer `[]` over `new Array()`. Prefer `[4, 5]` over `new Array(4, 5)`. Prefer `[undefined, undefined]` over `new Array(2)`. Since 2.0.10, this rule can be configured to allow `Array` type parameters. To ignore type parameters, configure the rule with the values: `[true, {"allow-type-parameters": true}]`. Since 6.2.0-beta, you can lift restriction on `Array` constructor calls with a single argument (to create empty array of a given length). If type information is available - rule will allow only a single argument of `number` type. To allow empty array creation, configure the rule with the values: `[true, {"allow-size-argument": true}]`. This rule has some overlap with the TSLint array-type rule; however, the version here catches more instances.	1.0, 2.0.10, 6.2.0-beta
`prefer-type-cast`	Prefer the tradition type casts instead of the new 'as-cast' syntax. For example, prefer `<string>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. This rule has some overlap with the tslint no-floating-promises rule, but they are substantially different.	1.0
`react-a11y-accessible-headings`	For accessibility of your website, there should be no more than 2 H1 heading elements, HTML heading elements must be concise, used for structuring information on the page and non-empty.	6.0.0
`react-a11y-anchors`	For accessibility of your website, anchor element link text should be at least 4 characters long. Links with the same HREF should have the same link text. Links that point to different HREFs should have different link text. This can be relaxed to allow differences in cases using `ignore-case` option. You can also allow differences in leading/trailing whitespace by adding `{"ignore-whitespace": "trim"}` option or all whitespace by adding `{"ignore-whitespace": "all"}` option. Links with images and text content, the alt attribute should be unique to the text content or empty. An an anchor element's href prop value must not be undefined, null, or just #. References: WCAG Rule 38: Link text should be as least four 4 characters long WCAG Rule 39: Links with the same HREF should have the same link text WCAG Rule 41: Links that point to different HREFs should have different link text WCAG Rule 43: Links with images and text content, the alt attribute should be unique to the text content or empty	2.0.11
`react-a11y-aria-unsupported-elements`	For accessibility of your website, enforce that elements that do not support ARIA roles, states, and properties do not have those attributes.	2.0.11
`react-a11y-event-has-role`	For accessibility of your website, elements with event handlers must have explicit role or implicit role. References: WCAG Rule 94 Using the button role	2.0.11
`react-a11y-iframes`	Enforce that iframe elements are not empty, have title, and are unique.	6.1.0
`react-a11y-image-button-has-alt`	For accessibility of your website, enforce that inputs element with `type="image"` must have non-empty alt attribute.	2.0.11
`react-a11y-img-has-alt`	Enforce that an `img` element contains the `alt` attribute or `role='presentation'` for a decorative image. All images must have `alt` text to convey their purpose and meaning to screen reader users. Besides, the `alt` attribute specifies an alternate text for an image, if the image cannot be displayed. This rule accepts as a parameter a string array for tag names other than img to also check. For example, if you use a custom tag named 'Image' then configure the rule with: `[true, ['Image']]`. References: Web Content Accessibility Guidelines 1.0 ARIA Presentation Role WCAG Rule 31: If an image has an alt or title attribute, it should not have a presentation role	2.0.11
`react-a11y-input-elements`	For accessibility of your website, HTML input boxes and text areas must include default, place-holding characters. References: WCAG 10.4 WCAG 11.5	6.0.0-beta
`react-a11y-lang`	For accessibility of your website, HTML elements must have a lang attribute and the attribute must be a valid language code. References: H58: Using language attributes to identify changes in the human language lang attribute must have a valid value List of ISO 639-1 codes	2.0.11
`react-a11y-meta`	For accessibility of your website, HTML meta elements must not have `http-equiv="refresh"`.	2.0.11
`react-a11y-mouse-event-has-key-event`	For accessibility of your website, elements with mouseOver/mouseOut should be accompanied by onFocus/onBlur keyboard events.	6.2.0-beta
`react-a11y-no-onchange`	For accessibility of your website, enforce usage of onBlur over onChange on select menus. References: OnChange Event Accessibility Issues Guideline 8. Ensure direct accessibility of embedded user interfaces.	6.0.0-beta
`react-a11y-props`	For accessibility of your website, enforce all `aria-` attributes are valid. Elements cannot use an invalid `aria-` attribute. This rule will fail if it finds an `aria-*` attribute that is not listed in WAI-ARIA states and properties.	2.0.11
`react-a11y-proptypes`	For accessibility of your website, enforce the type of aria state and property values are correct.	2.0.11
`react-a11y-required`	For accessibility of your website, enforce that required input elements have aria-required set to true. References: Acessibility in HTML5	6.0.0-beta
`react-a11y-role`	For accessibility of your website, elements with aria roles must use a valid, non-abstract aria role. A reference to role definitions can be found at [WAI-ARIA roles](https://www.w3.org/TR/wai-aria-1.1/#role_definitions). References: WCAG Rule 92: Role value must be valid	2.0.11
`react-a11y-role-has-required-aria-props`	For accessibility of your website, elements with aria roles must have all required attributes according to the role. References: ARIA Definition of Roles WCAG Rule 90: Required properties and states should be defined WCAG Rule 91: Required properties and states must not be empty	2.0.11
`react-a11y-role-supports-aria-props`	For accessibility of your website, enforce that elements with explicit or implicit roles defined contain only `aria-*` properties supported by that `role`. Many aria attributes (states and properties) can only be used on elements with particular roles. Some elements have implicit roles, such as `<a href='hrefValue' />`, which will be resolved to `role='link'`. A reference for the implicit roles can be found at Default Implicit ARIA Semantics. References: ARIA attributes can only be used with certain roles Check aria properties and states for valid roles and properties Check that 'ARIA-' attributes are valid properties and states	2.0.11
`react-a11y-tabindex-no-positive`	For accessibility of your website, enforce tabindex value is not greater than zero. Avoid positive tabindex attribute values to synchronize the flow of the page with keyboard tab order. References: WCAG 2.4.3 - Focus Order Audit Rules - tabindex-usage Avoid positive integer values for tabIndex	2.0.11
`react-a11y-titles`	For accessibility of your website, HTML title elements must not be empty, must be more than one word, and must not be more than 60 characters long. References: WCAG 2.0 - Requirement 2.4.2 Page Titled (Level A) OAA-Accessibility Rule 13: Title element should not be empty OAA-Accessibility Rule 24: Title content should be concise OAA-Accessibility Rule 25: Title text must contain more than one word	2.0.11
`react-anchor-blank-noopener`	For security reasons, anchor tags with `target="_blank"` should also include `rel="noreferrer"`. In order to restrict the behavior `window.opener` access, the original page needs to add a `rel="noopener"` attribute to any link that has `target="_blank"`. However, Firefox does not support that tag, so you should actually use `rel="noopener noreferrer"` for full coverage. By default, the rule considers the use of `rel="noreferrer"` as sufficient. The option `'force-rel-redundancy'` can be passed to require `rel="noopener noreferrer"`. For more info see: The target="_blank" vulnerability by example.	2.0.11
`react-iframe-missing-sandbox`	React iframes must specify a sandbox attribute. If specified as an empty string, this attribute enables extra restrictions on the content that can appear in the inline frame. The value of the attribute can either be an empty string (all the restrictions are applied), or a space-separated list of tokens that lift particular restrictions. You many not use both allow-scripts and allow-same-origin at the same time, as that allows the embedded document to programmatically remove the sandbox attribute in some scenarios.	2.0.10
`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
`react-this-binding-issue`	Several errors can occur when using React and React.Component subclasses. When using React components you must be careful to correctly bind the 'this' reference on any methods that you pass off to child components as callbacks. For example, it is common to define a private method called 'onClick' and then specify `onClick={this.onClick}` as a JSX attribute. If you do this then the 'this' reference will be undefined when your private method is invoked. The React documentation suggests that you bind the 'this' reference on all of your methods within the constructor: `this.onClick = this.onClick.bind(this);`. This rule will create a violation if: a method reference is passed to a JSX attribute without being bound in the constructor a method is bound multiple times in the constructor Another issue that can occur is binding the 'this' reference to a function within the render() method. For example, many people will create an anonymous lambda within the JSX attribute to avoid the 'this' binding issue: `onClick={() => { this.onClick(); }}`. The problem with this is that a new instance of an anonymous function is created every time render() is invoked. When React compares virutual DOM properties within shouldComponentUpdate() then the onClick property will look like a new property and force a re-render. You should avoid this pattern because creating function instances within render methods breaks any logic within shouldComponentUpdate() methods. This rule creates violations if: an anonymous function is passed as a JSX attribute if a function instantiated in local scope is passed as a JSX attribute This rule can be configured via the "allow-anonymous-listeners" parameter. If you want to suppress violations for the anonymous listener scenarios then configure that rule like this: `"react-this-binding-issue": [ true, { 'allow-anonymous-listeners': true } ]`, you can also pass in array of string which can act as bind method decorators: `"react-this-binding-issue": [true, {'bind-decorators': ['autobind']}]`	2.0.8, 2.0.9
`react-tsx-curly-spacing`	Consistently use spaces around the brace characters of JSX attributes. You can either allow or ban spaces between the braces and the values they enclose. One of the two following options are required: `"always"` enforces a space inside of curly braces (default) `"never"` disallows spaces inside of curly braces By default, braces spanning multiple lines are not allowed with either setting. If you want to allow them you can specify an additional allowMultiline property with the value false. Examples: `"react-tsx-curly-spacing": [true, "always"]` `"react-tsx-curly-spacing": [true, "never"]` `"react-tsx-curly-spacing": [true, "never", {"allowMultiline": false}]` References: eslint-plugin-react jsx-curly-spacing rule tslint-react jsx-curly-spacing rule	2.0.14
`react-unused-props-and-state`	Remove unneeded properties defined in React Props and State interfaces. Any interface named Props or State is defined as a React interface. All fields in these interfaces must be referenced. This rule can be configured with regexes to match custom Props and State interface names. Example for including all interfaces ending with Props or State: `[ true, { 'props-interface-regex': 'Props$', 'state-interface-regex': 'State$' } ]`.	2.0.10
`underscore-consistent-invocation`	Enforce a consistent usage of the _ functions. By default, invoking underscore functions should begin with wrapping a variable in an underscore instance: `_(list).map(...)`. An alternative is to prefer using the static methods on the _ variable: `_.map(list, ...)`. The rule accepts a single parameter called 'style' which can be the value 'static' or 'instance': `[true, { "style": "static" }]`.	2.0.10
`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
`use-simple-attributes`	Simpler attributes in JSX and TSX files helps keep code clean and readable. Separate complex expressions into their own line and use clear variable names to make your code more understandable.	6.0.0
`valid-typeof`	Deprecated - This rule is now enforced by the TypeScript compiler. 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
`void-zero`	`void 0`, which resolves to `undefined`, can be confusing to newcomers. Exclusively use `undefined` to reduce ambiguity.	6.1.0

Development

See CONTRIBUTING.md.

Release notes

Check GitHub Releases for individual release notes or CHANGELOG.md for full project changelog.

tslint-microsoft-contrib dependencies

tsutils

FAQs

What is tslint-microsoft-contrib?

TSLint Rules for Microsoft. Visit Snyk Advisor to see a full health score report for tslint-microsoft-contrib, including popularity, security, maintenance & community analysis.

Is tslint-microsoft-contrib popular?

The npm package tslint-microsoft-contrib receives a total of 112,161 weekly downloads. As such, tslint-microsoft-contrib popularity was classified as a popular. Visit the popularity section on Snyk Advisor to see the full health analysis.

Is tslint-microsoft-contrib well maintained?

We found indications that tslint-microsoft-contrib is an Inactive project. See the full package health analysis to learn more about the package maintenance status.

Is tslint-microsoft-contrib safe to use?

The npm package tslint-microsoft-contrib was scanned for known vulnerabilities and missing license, and no issues were found. Thus the package was deemed as safe to use. See the full health analysis review.

Last updated on 21 December-2024, at 07:24 (UTC).

Build a secure application checklist

Select a recommended open source package

Minimize your risk by selecting secure & well maintained open source packages

DONE

Scan your app for vulnerabilities

Scan your application to find vulnerabilities in your: source code, open source dependencies, containers and configuration files

SCAN NOW

Fix identified vulnerabilities

Easily fix your code by leveraging automatically generated PRs

AUTO FIX

Monitor for new issues

New vulnerabilities are discovered every day. Get notified if your application is affected

MONITOR APP