Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding stricter rules from microsoft-tslint-contrib #4

Open
charrondev opened this issue Jul 17, 2018 · 0 comments
Open

Consider adding stricter rules from microsoft-tslint-contrib #4

charrondev opened this issue Jul 17, 2018 · 0 comments

Comments

@charrondev
Copy link
Contributor

charrondev commented Jul 17, 2018

Some rules rules that seem like they would be appropriate to enable.
https://github.com/Microsoft/tslint-microsoft-contrib


Rule Name Description Since
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'. 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
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
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 , "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 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
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 repositiory 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-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. 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-delete-expression Do not delete expressions. Only properties should be deleted 0.0.2
no-document-write Do not use document.write 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-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 1) the import name will be consistent across all files and subdirectories so searching for usages is much easier. 2) 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. And 4) version control diffs will be simplified by having overall fewer edits to the import lines. 2.0.5
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-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-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-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-useless-files Avoid keeping files around that only contain commented out code, are completely empty, or only contain whitespace characters 4.0.2
non-literal-require Detect require() function calls for something that is not a string literal. For security reasons, it is best to only require() string literals. Otherwise, it is perhaps possible for an attacker to somehow change the value and download arbitrary Javascript into your page. 2.0.14
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-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. 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 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-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-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-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-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-role For accessibility of your website, elements with aria roles must use a valid, non-abstract aria role. A reference to role defintions can be found at WAI-ARIA roles. References:
* WCAG Rule 92: Role value must be valid
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="noopener 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. 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-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 1) a method reference is passed to a JSX attribute without being bound in the constructor. And 2) 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 virutal 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 1) an anonymous function is passed as a JSX attribute. And 2) 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 } ] 2.0.8, 2.0.9
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant