@tsslint/config 3.0.0-alpha.0 → 3.0.0-alpha.1

package/lib/tslint-types.d.ts

@@ -0,0 +1,3793 @@
+export interface TSLintRulesConfig {
+	/**
+	 * @rulesDirectory tools/tslint
+	 * @error Directory import '/Users/johnsonchu/Desktop/GitHub/angular/node_modules/tslint/lib' is not supported resolving ES modules imported from /Users/johnsonchu/Desktop/GitHub/angular/tools/tslint/requireInternalWithUnderscoreRule.ts
+Did you mean to import "tslint/lib/index.js"?
+	 */
+	'require-internal-with-underscore'?: any[],
+	/**
+	 * @rulesDirectory tools/tslint
+	 */
+	'ts-node-loader'?: any[],
+	/**
+	 * Enforces function overloads to be consecutive.
+	 *
+	 * @rationale
+	 * Improves readability and organization by grouping naturally related items together.
+	 *
+	 * @options
+	 * If `ignore-accessors` is specified, then getters and setters are not considered to be overloads
+	 * of function with the same signature.
+	 *
+	 * @example
+	 * "adjacent-overload-signatures": true
+	 * "adjacent-overload-signatures": [true,{"OPTION_IGNORE_ACCESSORS":true}]
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'adjacent-overload-signatures'?: {
+		'ignore-accessors'?: boolean,
+	},
+	/**
+	 * Enforces vertical alignment.
+	 *
+	 * @rationale
+	 * Helps maintain a readable, consistent style in your codebase.
+	 * 
+	 * Consistent alignment for code statements helps keep code readable and clear.
+	 * Statements misaligned from the standard can be harder to read and understand.
+	 *
+	 * @options
+	 * Five arguments may be optionally provided:
+	 * 
+	 * * `"parameters"` checks alignment of function parameters.
+	 * * `"arguments"` checks alignment of function call arguments.
+	 * * `"statements"` checks alignment of statements.
+	 * * `"members"` checks alignment of members of classes, interfaces, type literal, object literals and
+	 * object destructuring.
+	 * * `"elements"` checks alignment of elements of array literals, array destructuring and tuple types.
+	 *
+	 * @example
+	 * "align": [true,"parameters","statements"]
+	 *
+	 * @type formatting
+	 */
+	'align'?: ("arguments" | "elements" | "members" | "parameters" | "statements")[],
+	/**
+	 * Requires using either 'T[]' or 'Array<T>' for arrays.
+	 *
+	 * @options
+	 * One of the following arguments must be provided:
+	 * 
+	 * * `"array"` enforces use of `T[]` for all types T.
+	 * * `"generic"` enforces use of `Array<T>` for all types T.
+	 * * `"array-simple"` enforces use of `T[]` if `T` is a simple type (primitive or type reference).
+	 *
+	 * @example
+	 * "array-type": [true,"array"]
+	 * "array-type": [true,"generic"]
+	 * "array-type": [true,"array-simple"]
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'array-type'?: "array" | "generic" | "array-simple",
+	/**
+	 * Requires parentheses around the parameters of arrow function definitions.
+	 *
+	 * @rationale
+	 * Maintains stylistic consistency with other arrow function definitions.
+	 *
+	 * @options
+	 * If `ban-single-arg-parens` is specified, then arrow functions with one parameter
+	 * must not have parentheses if removing them is allowed by TypeScript.
+	 *
+	 * @example
+	 * "arrow-parens": true
+	 * "arrow-parens": [true,"ban-single-arg-parens"]
+	 *
+	 * @type formatting
+	 */
+	'arrow-parens'?: "ban-single-arg-parens",
+	/**
+	 * Suggests to convert `() => { return x; }` to `() => x`.
+	 *
+	 * @rationale
+	 * It's unnecessary to include `return` and `{}` brackets in arrow lambdas.
+	 * Leaving them out results in simpler and easier to read code.
+	 *
+	 * @options
+	 * If `multiline` is specified, then this will warn even if the function spans multiple lines.
+	 *
+	 * @example
+	 * "arrow-return-shorthand": true
+	 * "arrow-return-shorthand": [true,"multiline"]
+	 *
+	 * @type style
+	 */
+	'arrow-return-shorthand'?: "multiline",
+	/**
+	 * Warns for an awaited value that is not a Promise.
+	 *
+	 * @rationale
+	 * While it is valid JavaScript to await a non-Promise-like value (it will resolve immediately),
+	 * this pattern is often a programmer error and the resulting semantics can be unintuitive.
+	 * 
+	 * Awaiting non-Promise-like values often is an indication of programmer error, such as
+	 * forgetting to add parenthesis to call a function that returns a Promise.
+	 *
+	 * @options
+	 * A list of 'string' names of any additional classes that should also be treated as Promises.
+	 * For example, if you are using a class called 'Future' that implements the Thenable interface,
+	 * you might tell the rule to consider type references with the name 'Future' as valid Promise-like
+	 * types. Note that this rule doesn't check for type assignability or compatibility; it just checks
+	 * type reference names.
+	 *
+	 * @example
+	 * "await-promise": true
+	 * "await-promise": [true,"Thenable"]
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'await-promise'?: unknown,
+	/**
+	 * Disallows the comma operator to be used.
+	 *
+	 * [Read more about the comma operator here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comma_Operator).
+	 *
+	 * @rationale
+	 * Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code.
+	 * 
+	 * ### Examples
+	 * ```
+	 * foo((bar, baz)); // evaluates to 'foo(baz)' because of the extra parens - confusing and not obvious
+	 * ```
+	 * 
+	 * ```
+	 * switch (foo) {
+	 *     case 1, 2: // equals 'case 2' - probably intended 'case 1: case2:'
+	 *         return true;
+	 *     case 3:
+	 *         return false;
+	 * }
+	 * ```
+	 * 
+	 * ```
+	 * let x = (y = 1, z = 2); // x is equal to 2 - this may not be immediately obvious.
+	 * ```
+	 *
+	 * @example
+	 * "ban-comma-operator": true
+	 *
+	 * @type functionality
+	 */
+	'ban-comma-operator'?: any[],
+	/**
+	 * Bans the use of specific functions or global methods.
+	 *
+	 * @options
+	 * A list of banned functions or methods in the following format:
+	 * 
+	 * * banning functions:
+	 *   * just the name of the function: `"functionName"`
+	 *   * the name of the function in an array with one element: `["functionName"]`
+	 *   * an object in the following format: `{"name": "functionName", "message": "optional explanation message"}`
+	 * * banning methods:
+	 *   * an array with the object name, method name and optional message: `["objectName", "methodName", "optional message"]`
+	 *   * an object in the following format: `{"name": ["objectName", "methodName"], "message": "optional message"}`
+	 *     * you can also ban deeply nested methods: `{"name": ["foo", "bar", "baz"]}` bans `foo.bar.baz()`
+	 *     * the first element can contain a wildcard (`*`) that matches everything. `{"name": ["*", "forEach"]}` bans                  `[].forEach(...)`, `$(...).forEach(...)`, `arr.forEach(...)`, etc.
+	 *
+	 * @example
+	 * "ban": [true,"eval",{"name":"$","message":"please don't"},["describe","only"],{"name":["it","only"],"message":"don't focus tests"},{"name":["chai","assert","equal"],"message":"Use 'strictEqual' instead."},{"name":["*","forEach"],"message":"Use a regular for loop instead."},{"name":["*","_id","toString"],"message":"Use 'toHexString' instead."}]
+	 *
+	 * @type functionality
+	 */
+	'ban'?: unknown,
+	/**
+	 * Bans "// @ts-ignore" comments from being used.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "ban-ts-ignore": true
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'ban-ts-ignore'?: any[],
+	/**
+	 * Bans specific types from being used. Does not ban the
+	 * corresponding runtime objects from being used.
+	 *
+	 * @options
+	 * A list of `["regex", "optional explanation here"]`, which bans
+	 * types that match `regex`
+	 *
+	 * @example
+	 * "ban-types": [true,["Object","Use {} instead."],["String"]]
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'ban-types'?: unknown,
+	/**
+	 * In a binary expression, a literal should always be on the right-hand side if possible.
+	 * For example, prefer 'x + 1' over '1 + x'.
+	 *
+	 * @rationale
+	 * Expressions like `1 + x` are sometimes referred to as "Yoda" expressions because they read
+	 * opposite to how we would normally speak the expression.
+	 * 
+	 * Sticking to a consistent grammar for conditions helps keep code readable and understandable.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "binary-expression-operand-order": true
+	 *
+	 * @type style
+	 */
+	'binary-expression-operand-order'?: any[],
+	/**
+	 * An interface or literal type with just a call signature can be written as a function type.
+	 *
+	 * @rationale
+	 * style
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'callable-types'?: any[],
+	/**
+	 * Enforces PascalCased class and interface names.
+	 *
+	 * @rationale
+	 * Makes it easy to differentiate classes from regular variables at a glance.
+	 * 
+	 * JavaScript and general programming convention is to refer to classes in PascalCase.
+	 * It's confusing to use camelCase or other conventions for class names.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "class-name": true
+	 *
+	 * @type style
+	 */
+	'class-name'?: any[],
+	/**
+	 * Enforces formatting rules for single-line comments.
+	 *
+	 * @rationale
+	 * Helps maintain a consistent, readable style in your codebase.
+	 *
+	 * @options
+	 * Four arguments may be optionally provided:
+	 * 
+	 * * `"check-space"` requires that all single-line comments must begin with a space, as in `// comment`
+	 *     * note that for comments starting with multiple slashes, e.g. `///`, leading slashes are ignored
+	 *     * TypeScript reference comments are ignored completely
+	 * * `"check-lowercase"` requires that the first non-whitespace character of a comment must be lowercase, if applicable.
+	 * * `"check-uppercase"` requires that the first non-whitespace character of a comment must be uppercase, if applicable.
+	 * * `"allow-trailing-lowercase"` allows that only the first comment of a series of comments needs to be uppercase.
+	 *     * requires `"check-uppercase"`
+	 *     * comments must start at the same position
+	 * 
+	 * Exceptions to `"check-lowercase"` or `"check-uppercase"` can be managed with object that may be passed as last
+	 * argument.
+	 * 
+	 * One of two options can be provided in this object:
+	 * 
+	 * * `"ignore-words"`  - array of strings - words that will be ignored at the beginning of the comment.
+	 * * `"ignore-pattern"` - string - RegExp pattern that will be ignored at the beginning of the comment.
+	 *
+	 * @example
+	 * "comment-format": [true,"check-space","check-uppercase","allow-trailing-lowercase"]
+	 * "comment-format": [true,"check-lowercase",{"ignore-words":["TODO","HACK"]}]
+	 * "comment-format": [true,"check-lowercase",{"ignore-pattern":"STD\\w{2,3}\\b"}]
+	 *
+	 * @type style
+	 */
+	'comment-format'?: ("check-space" | "check-lowercase" | "check-uppercase" | "allow-trailing-lowercase" | {
+		'ignore-words'?: (string)[],
+		'ignore-pattern'?: string,
+	})[],
+	/**
+	 * Allows a limited set of comment types
+	 *
+	 * @options
+	 * One or more of the following mutually exclusive comment types may be provided:
+	 * 
+	 * * `singleline`: Comments starting with `//`
+	 * * `multiline`:  Comments between `/*` and `* /` but are not doc comments
+	 * * `doc`:        Multiline comments that start with `/**`
+	 * * 'directive':  Triple-slash directives that are singleline comments starting with `///`
+	 *
+	 * @example
+	 * "comment-type": [true,"doc","singleline"]
+	 * "comment-type": [true,"singleline"]
+	 * "comment-type": [true,"multiline"]
+	 *
+	 * @type style
+	 */
+	'comment-type'?: ("singleline" | "multiline" | "doc" | "directive")[],
+	/**
+	 * Enforces JSDoc comments for important items be filled out.
+	 *
+	 * @rationale
+	 * Helps ensure important components are documented.
+	 * 
+	 * Note: use this rule sparingly. It's better to have self-documenting names on components with single, concise responsibilities.
+	 * Comments that only restate the names of variables add nothing to code, and can easily become outdated.
+	 *
+	 * @options
+	 * `true` to enable for `[classes, functions, methods, properties]`,
+	 * or an array with each item in one of two formats:
+	 * 
+	 * * `string` to enable for that type
+	 * * `object` keying types to when their documentation is required:
+	 *     * `"methods"` and `"properties"` may specify:
+	 *         * `"privacies"`:
+	 *             * `"all"`
+	 *             * `"private"`
+	 *             * `"protected"`
+	 *             * `"public"`
+	 *         * `"locations"`:
+	 *             * `"all"`
+	 *             * `"instance"`
+	 *             * `"static"`
+	 *     * Other types may specify `"visibilities"`:
+	 *         * `"all"`
+	 *         * `"exported"`
+	 *         * `"internal"`
+	 *     * `"functions"` `"methods"` may also specify `"overloads"`
+	 *       to indicate that each overload should have its own documentation, which is `false` by default.
+	 *     * All types may also provide `"tags"`
+	 *       with members specifying tags that allow the docs to not have a body.
+	 *         * `"content"`: Object mapping tags to `RegExp` bodies content allowed to count as complete docs.
+	 *         * `"existence"`: Array of tags that must only exist to count as complete docs.
+	 * 
+	 * Types that may be enabled are:
+	 * 
+	 * * `"classes"`
+	 * * `"constructors"`
+	 * * `"enums"`
+	 * * `"enum-members"`
+	 * * `"functions"`
+	 * * `"interfaces"`
+	 * * `"methods"`
+	 * * `"namespaces"`
+	 * * `"properties"`
+	 * * `"types"`
+	 * * `"variables"`
+	 *
+	 * @example
+	 * "completed-docs": true
+	 * "completed-docs": [true,"enums","functions","methods"]
+	 * "completed-docs": [true,{"enums":true,"functions":{"visibilities":["exported"]},"methods":{"locations":"instance","privacies":["public","protected"]},"properties":{"tags":{"content":{"see":["#.*"]},"existence":["inheritdoc"]}}}]
+	 *
+	 * @type style
+	 */
+	'completed-docs'?: (string | {
+		classes?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			visibilities?: "all" | "exported" | "internal",
+		},
+		constructors?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			privacies?: "all" | "private" | "protected" | "public",
+			overloads?: boolean,
+		},
+		enums?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			visibilities?: "all" | "exported" | "internal",
+		},
+		'enum-members'?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			visibilities?: "all" | "exported" | "internal",
+		},
+		functions?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			visibilities?: "all" | "exported" | "internal",
+			overloads?: boolean,
+		},
+		interfaces?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			visibilities?: "all" | "exported" | "internal",
+		},
+		methods?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			locations?: "all" | "instance" | "static",
+			privacies?: "all" | "private" | "protected" | "public",
+			overloads?: boolean,
+		},
+		namespaces?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			visibilities?: "all" | "exported" | "internal",
+		},
+		properties?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			locations?: "all" | "instance" | "static",
+			privacies?: "all" | "private" | "protected" | "public",
+		},
+		types?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			visibilities?: "all" | "exported" | "internal",
+		},
+		variables?: {
+			tags?: {
+				content?: { [key: string]: unknown },
+				existence?: (string)[],
+			},
+			visibilities?: "all" | "exported" | "internal",
+		},
+	})[],
+	/**
+	 * Enforces braces for `if`/`for`/`do`/`while` statements.
+	 *
+	 * @rationale
+	 * ```ts
+	 * if (foo === bar)
+	 *     foo++;
+	 *     bar++;
+	 * ```
+	 * 
+	 * In the code above, the author almost certainly meant for both `foo++` and `bar++`
+	 * to be executed only if `foo === bar`. However, they forgot braces and `bar++` will be executed
+	 * no matter what. This rule could prevent such a mistake.
+	 *
+	 * @options
+	 * One of the following options may be provided:
+	 * 
+	 * * `"as-needed"` forbids any unnecessary curly braces.
+	 * * `"ignore-same-line"` skips checking braces for control-flow statements
+	 * that are on one line and start on the same line as their control-flow keyword
+	 *
+	 * @example
+	 * "curly": true
+	 * "curly": [true,"ignore-same-line"]
+	 * "curly": [true,"as-needed"]
+	 *
+	 * @type functionality
+	 */
+	'curly'?: ("as-needed" | "ignore-same-line")[],
+	/**
+	 * Enforces a threshold of cyclomatic complexity.
+	 *
+	 * Cyclomatic complexity is assessed for each function of any type. A starting value of 0
+	 * is assigned and this value is then incremented for every statement which can branch the
+	 * control flow within the function. The following statements and expressions contribute
+	 * to cyclomatic complexity:
+	 * * `catch`
+	 * * `if` and `? :`
+	 * * `||` and `&&` due to short-circuit evaluation
+	 * * `for`, `for in` and `for of` loops
+	 * * `while` and `do while` loops
+	 * * `case` clauses that contain statements
+	 *
+	 * @rationale
+	 * Cyclomatic complexity is a code metric which indicates the level of complexity in a
+	 * function. High cyclomatic complexity indicates confusing code which may be prone to
+	 * errors or difficult to modify.
+	 * 
+	 * It's better to have smaller, single-purpose functions with self-documenting names.
+	 *
+	 * @options
+	 * An optional upper limit for cyclomatic complexity can be specified. If no limit option
+	 * is provided a default value of 20 will be used.
+	 *
+	 * @example
+	 * "cyclomatic-complexity": true
+	 * "cyclomatic-complexity": [true,20]
+	 *
+	 * @type maintainability
+	 */
+	'cyclomatic-complexity'?: number,
+	/**
+	 * Warns when deprecated APIs are used.
+	 *
+	 * Any usage of an identifier
+	 *             with the @deprecated JSDoc annotation will trigger a warning.
+	 *             See http://usejsdoc.org/tags-deprecated.html
+	 *
+	 * @rationale
+	 * Deprecated APIs should be avoided, and usage updated.
+	 *
+	 * @example
+	 * "deprecation": true
+	 *
+	 * @type maintainability
+	 */
+	'deprecation'?: any[],
+	/**
+	 * Enforces UTF-8 file encoding.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * true
+	 *
+	 * @type style
+	 */
+	'encoding'?: any[],
+	/**
+	 * Ensures the file ends with a newline.
+	 *
+	 * Fix for single-line files is not supported.
+	 *
+	 * @rationale
+	 * It is a [standard convention](https://stackoverflow.com/q/729692/3124288) to end files with a newline.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "eofline": true
+	 *
+	 * @type formatting
+	 */
+	'eofline'?: any[],
+	/**
+	 * Enforces a certain header comment for all files, matched by a regular expression.
+	 *
+	 * @options
+	 * A single object may be passed in for configuration that must contain:
+	 * 
+	 * * `match`: a regular expression that all headers should match
+	 * 
+	 * Any of the following optional fields may also be provided:
+	 * 
+	 * * `allow-single-line-comments`: a boolean for whether `//` should be considered file headers in addition to `/*` comments
+	 * * `default`: text to add for file headers when running in `--fix` mode
+	 * * `enforce-trailing-newline`: a boolean for whether a newline must follow the header
+	 * 
+	 * The rule will also accept array of strings as a legacy form of options, though the object form is recommended.
+	 * The first option, which is mandatory, is a regular expression that all headers should match.
+	 * The second argument, which is optional, is a string that should be inserted as a header comment
+	 * if fixing is enabled and no header that matches the first argument is found.
+	 * The third argument, which is optional, is a string that denotes whether or not a newline should
+	 * exist on the header.
+	 *
+	 * @example
+	 * "file-header": [true,{"match":"Copyright \\d{4}","allow-single-line-comments":true,"default":"Copyright 2018","enforce-trailing-newline":true}]
+	 * "file-header": [true,"Copyright \\d{4}","Copyright 2018","enforce-trailing-newline"]
+	 *
+	 * @type style
+	 */
+	'file-header'?: ({
+		match?: string,
+		'allow-single-line-comments'?: boolean,
+		default?: string,
+		'enforce-trailing-newline'?: boolean,
+	})[] | [string, string, string],
+	/**
+	 * Enforces a consistent file naming convention
+	 *
+	 * @rationale
+	 * Helps maintain a consistent style across a file hierarchy
+	 *
+	 * @options
+	 * One of the following arguments must be provided:
+	 * 
+	 * * `camel-case`: File names must be camel-cased: `fileName.ts`.
+	 * * `pascal-case`: File names must be Pascal-cased: `FileName.ts`.
+	 * * `kebab-case`: File names must be kebab-cased: `file-name.ts`.
+	 * * `snake-case`: File names must be snake-cased: `file_name.ts`.
+	 * * `ignore`: File names are ignored _(useful for the object configuration)_.
+	 * 
+	 * Or an object, where the key represents a regular expression that
+	 * matches the file name, and the value is the file name rule from
+	 * the previous list.
+	 * 
+	 * * { ".tsx": "pascal-case", ".ts": "camel-case" }
+	 *
+	 * @example
+	 * "file-name-casing": [true,"camel-case"]
+	 * "file-name-casing": [true,"pascal-case"]
+	 * "file-name-casing": [true,"kebab-case"]
+	 * "file-name-casing": [true,"snake-case"]
+	 * "file-name-casing": [true,{".tsx":"pascal-case",".ts":"camel-case"}]
+	 * "file-name-casing": [true,{".style.ts":"kebab-case",".tsx":"pascal-case",".*":"camel-case"}]
+	 * "file-name-casing": [true,{".ts":"ignore",".tsx":"pascal-case"}]
+	 *
+	 * @type style
+	 */
+	'file-name-casing'?: (["camel-case" | "ignore" | "pascal-case" | "kebab-case" | "snake-case"] | { [key: string]: unknown })[],
+	/**
+	 * Requires a `for ... in` statement to be filtered with an `if` statement.
+	 *
+	 * @rationale
+	 * ```ts
+	 * for (let key in someObject) {
+	 *     if (someObject.hasOwnProperty(key)) {
+	 *         // code here
+	 *     }
+	 * }
+	 * ```
+	 * Prevents accidental iteration over properties inherited from an object's prototype.
+	 * See [MDN's `for...in`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in)
+	 * documentation for more information about `for...in` loops.
+	 * 
+	 * Also consider using a [`Map`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map)
+	 * or [`Set`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set)
+	 * if you're storing collections of objects.
+	 * Using `Object`s can cause occasional edge case bugs, such as if a key is named "hasOwnProperty".
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "forin": true
+	 *
+	 * @type functionality
+	 */
+	'forin'?: any[],
+	/**
+	 * Prevents using the built-in Function constructor.
+	 *
+	 * @rationale
+	 * Calling the constructor directly is similar to `eval`, which is a symptom of design issues.
+	 * String inputs don't receive type checking and can cause performance issues, particularly when dynamically created.
+	 * 
+	 * If you need to dynamically create functions, use "factory" functions that themselves return functions.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "function-constructor": true
+	 *
+	 * @type functionality
+	 */
+	'function-constructor'?: any[],
+	/**
+	 * Disallows importing the specified modules via `import` and `require`,
+	 * or importing specific named exports of the specified modules,
+	 * or using imports matching specified regular expression patterns.
+	 *
+	 * @rationale
+	 * For some libraries, importing the library directly can cause unused
+	 * submodules to be loaded, so you may want to block these imports and
+	 * require that users directly import only the submodules they need.
+	 * In other cases, you may simply want to ban an import because using
+	 * it is undesirable or unsafe.
+	 *
+	 * @options
+	 * A list of blacklisted modules, named imports, or regular expression patterns.
+	 *
+	 * @example
+	 * "import-blacklist": true
+	 * "import-blacklist": [true,"rxjs","lodash"]
+	 * "import-blacklist": [true,[".*\\.temp$",".*\\.tmp$"]]
+	 * "import-blacklist": [true,{"lodash":["pull","pullAll"]}]
+	 * "import-blacklist": [true,"lodash",{"lodash":["pull","pullAll"]}]
+	 * "import-blacklist": [true,"rxjs",{"lodash":["pull","pullAll"]},[".*\\.temp$",".*\\.tmp$"]]
+	 *
+	 * @type functionality
+	 */
+	'import-blacklist'?: (string | { [key: string]: unknown } | (string)[])[],
+	/**
+	 * Ensures proper spacing between import statement keywords
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "import-spacing": true
+	 *
+	 * @type formatting
+	 */
+	'import-spacing'?: any[],
+	/**
+	 * Enforces using explicit += 1 or -= 1 operators.
+	 *
+	 * @rationale
+	 * It's easy to type +i or -i instead of --i or ++i, and won't always result in invalid code.
+	 * Prefer standardizing small arithmetic operations with the explicit += and -= operators.
+	 *
+	 * @options
+	 * If no arguments are provided, both pre- and post-unary operators are banned.
+	 * If `"allow-post"` is provided, post-unary operators will be allowed.
+	 *
+	 * @example
+	 * "increment-decrement": true
+	 * "increment-decrement": [true,"allow-post"]
+	 *
+	 * @type style
+	 */
+	'increment-decrement'?: ("allow-post")[],
+	/**
+	 * Enforces indentation with tabs or spaces.
+	 *
+	 * @rationale
+	 * Using only one of tabs or spaces for indentation leads to more consistent editor behavior,
+	 * cleaner diffs in version control, and easier programmatic manipulation.
+	 *
+	 * @options
+	 * One of the following arguments must be provided:
+	 * 
+	 * * `spaces` enforces consistent spaces.
+	 * * `tabs` enforces consistent tabs.
+	 * 
+	 * A second optional argument specifies indentation size:
+	 * 
+	 * * `2` enforces 2 space indentation.
+	 * * `4` enforces 4 space indentation.
+	 * 
+	 * Indentation size is **required** for auto-fixing, but not for rule checking.
+	 * 
+	 * **NOTE**: auto-fixing will only convert invalid indent whitespace to the desired type, it will not fix invalid whitespace sizes.
+	 *
+	 * @example
+	 * "indent": [true,"spaces"]
+	 * "indent": [true,"spaces",4]
+	 * "indent": [true,"tabs",2]
+	 *
+	 * @type formatting
+	 */
+	'indent'?: ["tabs" | "spaces", 2 | 4],
+	/**
+	 * Requires interface names to begin with a capital 'I'
+	 *
+	 * @rationale
+	 * Makes it easy to differentiate interfaces from regular classes at a glance.
+	 *
+	 * @options
+	 * One of the following two options must be provided:
+	 * 
+	 * * `"always-prefix"` requires interface names to start with an "I"
+	 * * `"never-prefix"` requires interface names to not have an "I" prefix
+	 *
+	 * @example
+	 * "interface-name": [true,"always-prefix"]
+	 * "interface-name": [true,"never-prefix"]
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'interface-name'?: "always-prefix" | "never-prefix",
+	/**
+	 * Prefer an interface declaration over a type literal (`type T = { ... }`)
+	 *
+	 * @rationale
+	 * Interfaces are generally preferred over type literals because interfaces can be implemented, extended and merged.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "interface-over-type-literal": true
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'interface-over-type-literal'?: any[],
+	/**
+	 * Disallows usage of `void` type outside of generic or return types.
+	 * If `void` is used as return type, it shouldn't be a part of intersection/union type.
+	 *
+	 * @rationale
+	 * The `void` type means "nothing" or that a function does not return any value,
+	 * in contra with implicit `undefined` type which means that a function returns a value `undefined`.
+	 * So "nothing" cannot be mixed with any other types.
+	 * If you need this - use `undefined` type instead.
+	 *
+	 * @options
+	 * If `allow-generics` is specified as `false`, then generic types will no longer be allowed to to be `void`.
+	 * Alternately, provide an array of strings for `allow-generics` to exclusively allow generic types by those names.
+	 *
+	 * @example
+	 * "invalid-void": true
+	 * "invalid-void": [true,{"allow-generics":false}]
+	 * "invalid-void": [true,{"allow-generics":["Promise","PromiseLike"]}]
+	 *
+	 * @type maintainability
+	 *
+	 * @typescriptOnly
+	 */
+	'invalid-void'?: {
+		'allow-generics'?: boolean | (string)[],
+	},
+	/**
+	 * Enforces basic format rules for JSDoc comments.
+	 *
+	 * The following rules are enforced for JSDoc comments (comments starting with `/**`):
+	 * 
+	 * * each line contains an asterisk and asterisks must be aligned
+	 * * each asterisk must be followed by either a space or a newline (except for the first and the last)
+	 * * the only characters before the asterisk on each line must be whitespace characters
+	 * * one line comments must start with `/** ` and end with `* /`
+	 * * multiline comments don't allow text after `/** ` in the first line (with option `"check-multiline-start"`)
+	 *
+	 * @rationale
+	 * Helps maintain a consistent, readable style for JSDoc comments.
+	 *
+	 * @options
+	 * You can optionally specify the option `"check-multiline-start"` to enforce the first line of a
+	 * multiline JSDoc comment to be empty.
+	 *
+	 * @example
+	 * "jsdoc-format": true
+	 * "jsdoc-format": [true,"check-multiline-start"]
+	 *
+	 * @type formatting
+	 */
+	'jsdoc-format'?: ("check-multiline-start")[],
+	/**
+	 * Only allows labels in sensible locations.
+	 *
+	 * This rule only allows labels to be on `do/for/while/switch` statements.
+	 *
+	 * @rationale
+	 * Labels in JavaScript only can be used in conjunction with `break` or `continue`,
+	 * constructs meant to be used for loop flow control. While you can theoretically use
+	 * labels on any block statement in JS, it is considered poor code structure to do so.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "label-position": true
+	 *
+	 * @type functionality
+	 */
+	'label-position'?: any[],
+	/**
+	 * Enforces a consistent linebreak style.
+	 *
+	 * @options
+	 * One of the following options must be provided:
+	 * 
+	 * * `"LF"` requires LF (`\n`) linebreaks
+	 * * `"CRLF"` requires CRLF (`\r\n`) linebreaks
+	 *
+	 * @example
+	 * "linebreak-style": [true,"LF"]
+	 * "linebreak-style": [true,"CRLF"]
+	 *
+	 * @type formatting
+	 */
+	'linebreak-style'?: "LF" | "CRLF",
+	/**
+	 * Requires that a default import have the same name as the declaration it imports.
+	 * Does nothing for anonymous default exports.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "match-default-export-name": true
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'match-default-export-name'?: any[],
+	/**
+	 * A file may not contain more than the specified number of classes
+	 *
+	 * @rationale
+	 * Ensures that files have a single responsibility so that that classes each exist in their own files
+	 *
+	 * @options
+	 * The one required argument is an integer indicating the maximum number of classes that can appear in a
+	 * file. An optional argument `"exclude-class-expressions"` can be provided to exclude class expressions
+	 * from the overall class count.
+	 *
+	 * @example
+	 * "max-classes-per-file": [true,1]
+	 * "max-classes-per-file": [true,5,"exclude-class-expressions"]
+	 *
+	 * @type maintainability
+	 */
+	'max-classes-per-file'?: [number, "exclude-class-expressions"],
+	/**
+	 * Requires files to remain under a certain number of lines
+	 *
+	 * @rationale
+	 * Limiting the number of lines allowed in a file allows files to remain small,
+	 * single purpose, and maintainable.
+	 *
+	 * @options
+	 * An integer indicating the maximum number of lines.
+	 *
+	 * @example
+	 * "max-file-line-count": [true,300]
+	 *
+	 * @type maintainability
+	 */
+	'max-file-line-count'?: number,
+	/**
+	 * Requires lines to be under a certain max length.
+	 *
+	 * @rationale
+	 * Limiting the length of a line of code improves code readability.
+	 * It also makes comparing code side-by-side easier and improves compatibility with
+	 * various editors, IDEs, and diff viewers.
+	 *
+	 * @options
+	 * It can take one argument, which can be any of the following:
+	 * * integer indicating maximum length of lines.
+	 * * object with keys:
+	 *   * `limit` - number greater than 0 defining the max line length
+	 *   * `ignore-pattern` - string defining ignore pattern for this rule, being parsed by `new RegExp()`.
+	 *     For example:
+	 *      * `// ` pattern will ignore all in-line comments.
+	 *      * `^import ` pattern will ignore all import statements.
+	 *      * `^export {(.*?)}` pattern will ignore all multiple export statements.
+	 *      * `class [a-zA-Z]+ implements ` pattern will ignore all class declarations implementing interfaces.
+	 *      * `^import |^export {(.*?)}|class [a-zA-Z]+ implements |// ` pattern will ignore all the cases listed above.
+	 *   * `check-strings` - determines if strings should be checked, `false` by default.
+	 *   * `check-regex` - determines if regular expressions should be checked, `false` by default.
+	 *
+	 * @example
+	 * "max-line-length": [true,120]
+	 * "max-line-length": [true,{"limit":120,"ignore-pattern":"^import |^export {(.*?)}","check-strings":true,"check-regex":true}]
+	 *
+	 * @type formatting
+	 */
+	'max-line-length'?: (number | {
+		limit?: number,
+		'ignore-pattern'?: string,
+		'check-strings'?: boolean,
+		'check-regex'?: boolean,
+	})[],
+	/**
+	 * Requires explicit visibility declarations for class members.
+	 *
+	 * @rationale
+	 * Explicit visibility declarations can make code more readable and accessible for those new to TS.
+	 * 
+	 * Other languages such as C# default to `private`, unlike TypeScript's default of `public`.
+	 * Members lacking a visibility declaration may be an indication of an accidental leak of class internals.
+	 *
+	 * @options
+	 * These arguments may be optionally provided:
+	 * 
+	 * * `"no-public"` forbids public accessibility to be specified, because this is the default.
+	 * * `"check-accessor"` enforces explicit visibility on get/set accessors
+	 * * `"check-constructor"`  enforces explicit visibility on constructors
+	 * * `"check-parameter-property"`  enforces explicit visibility on parameter properties
+	 *
+	 * @example
+	 * "member-access": true
+	 * "member-access": [true,"no-public"]
+	 * "member-access": [true,"check-accessor"]
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'member-access'?: ("no-public" | "check-accessor" | "check-constructor" | "check-parameter-property")[],
+	/**
+	 * Enforces member ordering.
+	 *
+	 * @rationale
+	 * A consistent ordering for class members can make classes easier to read, navigate, and edit.
+	 * 
+	 * A common opposite practice to `member-ordering` is to keep related groups of classes together.
+	 * Instead of creating classes with multiple separate groups, consider splitting class responsibilities
+	 * apart across multiple single-responsibility classes.
+	 *
+	 * @options
+	 * One argument, which is an object, must be provided. It should contain an `order` property.
+	 * The `order` property should have a value of one of the following strings:
+	 * 
+	 * * `fields-first`
+	 * * `instance-sandwich`
+	 * * `statics-first`
+	 * 
+	 * `fields-first` puts, in order of precedence:
+	 *     * fields before constructors before methods
+	 *     * static members before instance members
+	 *     * public members before protected members before private members
+	 * `instance-sandwich` puts, in order of precedence:
+	 *     * fields before constructors before methods
+	 *     * static fields before instance fields, but static methods *after* instance methods
+	 *     * public members before protected members before private members
+	 * `statics-first` puts, in order of precedence:
+	 *     * static members before instance members
+	 *         * public members before protected members before private members
+	 *         * fields before methods
+	 *     * instance fields before constructors before instance methods
+	 *         * fields before constructors before methods
+	 *         * public members before protected members before private members
+	 * Note that these presets, despite looking similar, can have subtly different behavior due to the order in which these
+	 * rules are specified. A fully expanded ordering can be found in the PRESETS constant in
+	 * https://github.com/palantir/tslint/blob/master/src/rules/memberOrderingRule.ts.
+	 * (You may need to check the version of the file corresponding to your version of tslint.)
+	 * 
+	 * Alternatively, the value for `order` may be an array consisting of the following strings:
+	 * 
+	 * * `public-static-field`
+	 * * `protected-static-field`
+	 * * `private-static-field`
+	 * * `public-static-method`
+	 * * `private-static-method`
+	 * * `protected-static-method`
+	 * * `public-instance-field`
+	 * * `protected-instance-field`
+	 * * `private-instance-field`
+	 * * `public-constructor`
+	 * * `protected-constructor`
+	 * * `private-constructor`
+	 * * `public-instance-method`
+	 * * `protected-instance-method`
+	 * * `private-instance-method`
+	 * * `public-static-accessor`
+	 * * `protected-static-accessor`
+	 * * `private-static-accessor`
+	 * * `public-instance-accessor`
+	 * * `protected-instance-accessor`
+	 * * `private-instance-accessor`
+	 * 
+	 * You can also omit the access modifier to refer to "public-", "protected-", and "private-" all at once; for example, "static-field".
+	 * 
+	 * You can also make your own categories by using an object instead of a string:
+	 * 
+	 *     {
+	 *         "name": "static non-private",
+	 *         "kinds": [
+	 *             "public-static-field",
+	 *             "protected-static-field",
+	 *             "public-static-method",
+	 *             "protected-static-method"
+	 *         ]
+	 *     }
+	 * 
+	 * The 'alphabetize' option will enforce that members within the same category should be alphabetically sorted by name.
+	 * Computed property names are sorted before others but not sorted amongst each other.
+	 * Additionally getters will be sorted before setters (after alphabetization).
+	 *
+	 * @example
+	 * "member-ordering": [true,{"order":"fields-first"}]
+	 * "member-ordering": [true,{"alphabetize":true,"order":["public-static-field","public-instance-field","public-constructor","private-static-field","private-instance-field","private-constructor","public-instance-method","protected-instance-method","private-instance-method"]}]
+	 * "member-ordering": [true,{"order":[{"name":"static non-private","kinds":["public-static-field","protected-static-field","public-static-method","protected-static-method"]},"constructor"]}]
+	 *
+	 * @type typescript
+	 */
+	'member-ordering'?: {
+		alphabetize?: boolean,
+		order?: "fields-first" | "instance-sandwich" | "statics-first" | ("public-static-field" | "protected-static-field" | "private-static-field" | "public-static-method" | "private-static-method" | "protected-static-method" | "public-instance-field" | "protected-instance-field" | "private-instance-field" | "public-constructor" | "protected-constructor" | "private-constructor" | "public-instance-method" | "protected-instance-method" | "private-instance-method" | "public-static-accessor" | "protected-static-accessor" | "private-static-accessor" | "public-instance-accessor" | "protected-instance-accessor" | "private-instance-accessor")[],
+	},
+	/**
+	 * Requires parentheses when invoking a constructor via the `new` keyword.
+	 *
+	 * @rationale
+	 * Maintains stylistic consistency with other function calls.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "new-parens": true
+	 *
+	 * @type formatting
+	 */
+	'new-parens'?: any[],
+	/**
+	 * Enforces blank line before return when not the only line in the block.
+	 *
+	 * @rationale
+	 * Helps maintain a readable style in your codebase.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "newline-before-return": true
+	 *
+	 * @type formatting
+	 */
+	'newline-before-return'?: unknown,
+	/**
+	 * Requires that chained method calls be broken apart onto separate lines.
+	 *
+	 * @rationale
+	 * This style helps to keep code 'vertical', avoiding the need for side-scrolling in IDEs or text editors.
+	 *
+	 * @options
+	 * Not configurable
+	 *
+	 * @type style
+	 */
+	'newline-per-chained-call'?: any[],
+	/**
+	 * Requires the use of `as Type` for type assertions instead of `<Type>`.
+	 *
+	 * @rationale
+	 * Both formats of type assertions have the same effect, but only `as` type assertions
+	 * work in `.tsx` files. This rule ensures that you have a consistent type assertion style
+	 * across your codebase.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-angle-bracket-type-assertion": true
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'no-angle-bracket-type-assertion'?: any[],
+	/**
+	 * Disallows usages of `any` as a type declaration.
+	 *
+	 * @rationale
+	 * Using `any` as a type declaration nullifies the compile-time benefits of the type system.
+	 * 
+	 * If you're dealing with data of unknown or "any" types, you shouldn't be accessing members of it.
+	 * Either add type annotations for properties that may exist or change the data type to the empty object type `{}`.
+	 * 
+	 * Alternately, if you're creating storage or handling for consistent but unknown types, such as in data structures
+	 * or serialization, use `<T>` template types for generic type handling.
+	 * 
+	 * Also see the `no-unsafe-any` rule.
+	 *
+	 * @options
+	 * If `"ignore-rest-args": true` is provided rest arguments will be ignored.
+	 *
+	 * @example
+	 * "no-any": true
+	 * "no-any": [true,{"ignore-rest-args":true}]
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'no-any'?: {
+		'ignore-rest-args'?: boolean,
+	},
+	/**
+	 * Disallows use of `arguments.callee`.
+	 *
+	 * @rationale
+	 * Using `arguments.callee` makes various performance optimizations impossible.
+	 * See [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments/callee)
+	 * for more details on why to avoid `arguments.callee`.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-arg": true
+	 *
+	 * @type functionality
+	 */
+	'no-arg'?: any[],
+	/**
+	 * Functions marked async must contain an await or return statement.
+	 *
+	 * @rationale
+	 * Marking a function as `async` without using `await` or returning a value inside it can lead to an unintended promise return and a larger transpiled output.
+	 * Often the function can be synchronous and the `async` keyword is there by mistake.
+	 * Return statements are allowed as sometimes it is desirable to wrap the returned value in a Promise.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-async-without-await": true
+	 *
+	 * @type functionality
+	 */
+	'no-async-without-await'?: any[],
+	/**
+	 * Disallows bitwise operators.
+	 *
+	 * Specifically, the following bitwise operators are banned:
+	 * `&`, `&=`, `|`, `|=`,
+	 * `^`, `^=`, `<<`, `<<=`,
+	 * `>>`, `>>=`, `>>>`, `>>>=`, and `~`.
+	 * This rule does not ban the use of `&` and `|` for intersection and union types.
+	 *
+	 * @rationale
+	 * Bitwise operators are often typos - for example `bool1 & bool2` instead of `bool1 && bool2`.
+	 * They also can be an indicator of overly clever code which decreases maintainability.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-bitwise": true
+	 *
+	 * @type functionality
+	 */
+	'no-bitwise'?: any[],
+	/**
+	 * Warns on comparison to a boolean literal, as in `x === true`.
+	 *
+	 * @rationale
+	 * Comparing boolean values to boolean literals is unnecessary, as those expressions will result in booleans too.
+	 * Just use the boolean values directly or negate them.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-boolean-literal-compare": true
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'no-boolean-literal-compare'?: any[],
+	/**
+	 * Disallows any type of assignment in conditionals.
+	 *
+	 * This applies to `do-while`, `for`, `if`, and `while` statements and conditional (ternary) expressions.
+	 *
+	 * @rationale
+	 * Assignments in conditionals are often typos:
+	 * for example `if (var1 = var2)` instead of `if (var1 == var2)`.
+	 * They also can be an indicator of overly clever code which decreases maintainability.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-conditional-assignment": true
+	 *
+	 * @type functionality
+	 */
+	'no-conditional-assignment'?: any[],
+	/**
+	 * Disallows one or more blank lines in a row.
+	 *
+	 * @rationale
+	 * Helps maintain a readable style in your codebase.
+	 * 
+	 * Extra blank lines take up extra space and add little to a semantic understanding of the code.
+	 * It can be harder to read through files when fewer components can fit into the screen.
+	 * If you find a file is so large you feel a need to split them up with extra blank lines or comments,
+	 * consider splitting your file into smaller files.
+	 *
+	 * @options
+	 * An optional number of maximum allowed sequential blanks can be specified. If no value
+	 * is provided, a default of 1 will be used.
+	 *
+	 * @example
+	 * "no-consecutive-blank-lines": true
+	 * "no-consecutive-blank-lines": [true,2]
+	 *
+	 * @type formatting
+	 */
+	'no-consecutive-blank-lines'?: number,
+	/**
+	 * Bans the use of specified `console` methods.
+	 *
+	 * @rationale
+	 * In general, `console` methods aren't appropriate for production code.
+	 *
+	 * @options
+	 * A list of method names to ban. If no method names are provided, all console methods are banned.
+	 *
+	 * @example
+	 * "no-console": [true,"log","error"]
+	 *
+	 * @type functionality
+	 */
+	'no-console'?: (string)[],
+	/**
+	 * Disallows access to the constructors of `String`, `Number`, and `Boolean`.
+	 *
+	 * Disallows constructor use such as `new Number(foo)` but does not disallow `Number(foo)`.
+	 *
+	 * @rationale
+	 * There is little reason to use `String`, `Number`, or `Boolean` as constructors.
+	 * In almost all cases, the regular function-call version is more appropriate.
+	 * [More details](http://stackoverflow.com/q/4719320/3124288) are available on StackOverflow.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-construct": true
+	 *
+	 * @type functionality
+	 */
+	'no-construct'?: any[],
+	/**
+	 * Disallows `debugger` statements.
+	 *
+	 * @rationale
+	 * In general, `debugger` statements aren't appropriate for production code.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-debugger": true
+	 *
+	 * @type functionality
+	 */
+	'no-debugger'?: any[],
+	/**
+	 * Disallows default exports in ES6-style modules.
+	 *
+	 * Use named exports instead.
+	 *
+	 * @rationale
+	 * Named imports/exports [promote clarity](https://github.com/palantir/tslint/issues/1182#issue-151780453).
+	 * In addition, current tooling differs on the correct way to handle default imports/exports.
+	 * Avoiding them all together can help avoid tooling bugs and conflicts.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-default-export": true
+	 *
+	 * @type maintainability
+	 */
+	'no-default-export'?: any[],
+	/**
+	 * Disallows importing default members from certain ES6-style modules.
+	 *
+	 * Import named members instead.
+	 *
+	 * @rationale
+	 * Named imports/exports [promote clarity](https://github.com/palantir/tslint/issues/1182#issue-151780453).
+	 * In addition, current tooling differs on the correct way to handle default imports/exports.
+	 * Avoiding them all together can help avoid tooling bugs and conflicts.
+	 * 
+	 * The rule supposed to narrow the scope of your changes in the case of monorepo.
+	 * Say, you have packages `A`, `B`, `C` and `utils`, where `A`, `B`, `C` dependends on `utils`,
+	 * which is full of default exports.
+	 * `"no-default-export"` requires you to remove default _export_ from `utils`, which leads to changes
+	 * in packages `A`, `B`, `C`. It's harder to get merged bigger changeset by various reasons (harder to get your code approved
+	 * due to a number of required reviewers; longer build time due to a number of affected packages)
+	 * and could result in ignored `"no-default-export"` rule in `utils'`.
+	 * 
+	 * Unlike `"no-default-export"`, the rule requires you to replace default _import_ with named only in `A` you work on,
+	 * and `utils` you import from.
+	 *
+	 * @options
+	 * optionsDescription
+	 *
+	 * @example
+	 * "no-default-import": [true,{"fromModules":"^palantir-|^_internal-*|^\\./|^\\.\\./"}]
+	 *
+	 * @type maintainability
+	 */
+	'no-default-import'?: ({
+		fromModules: string,
+	})[],
+	/**
+	 * Disallows multiple import statements from the same module.
+	 *
+	 * @rationale
+	 * Using a single import statement per module will make the code clearer because you can see everything being imported
+	 * from that module on one line.
+	 *
+	 * @options
+	 * "allow-namespace-imports" allows you to import namespaces on separate lines.
+	 *
+	 * @example
+	 * "no-duplicate-imports": [true,{"allow-namespace-imports":true}]
+	 *
+	 * @type maintainability
+	 */
+	'no-duplicate-imports'?: {
+		'allow-namespace-imports'?: boolean,
+	},
+	/**
+	 * Warns if 'super()' appears twice in a constructor.
+	 *
+	 * @rationale
+	 * The second call to 'super()' will fail at runtime.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-duplicate-super": true
+	 *
+	 * @type functionality
+	 */
+	'no-duplicate-super'?: any[],
+	/**
+	 * Prevents duplicate cases in switch statements.
+	 *
+	 * @example
+	 * "no-duplicate-switch-case": true
+	 *
+	 * @type functionality
+	 */
+	'no-duplicate-switch-case'?: any[],
+	/**
+	 * Disallows duplicate variable declarations in the same block scope.
+	 *
+	 * This rule is only useful when using the `var` keyword -
+	 * the compiler will detect redeclarations of `let` and `const` variables.
+	 *
+	 * @rationale
+	 * A variable can be reassigned if necessary -
+	 * there's no good reason to have a duplicate variable declaration.
+	 *
+	 * @options
+	 * You can specify `"check-parameters"` to check for variables with the same name as a parameter.
+	 *
+	 * @example
+	 * "no-duplicate-variable": true
+	 * "no-duplicate-variable": [true,"check-parameters"]
+	 *
+	 * @type functionality
+	 */
+	'no-duplicate-variable'?: "check-parameters",
+	/**
+	 * Bans usage of the delete operator with computed key expressions.
+	 *
+	 * @rationale
+	 * Deleting dynamically computed keys is dangerous and not well optimized.
+	 * 
+	 * Also consider using a [`Map`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map)
+	 * or [`Set`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set)
+	 * if you're storing collections of objects.
+	 * Using `Object`s can cause occasional edge case bugs, such as if a key is named "hasOwnProperty".
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-dynamic-delete": true
+	 *
+	 * @type functionality
+	 */
+	'no-dynamic-delete'?: any[],
+	/**
+	 * Forbids empty interfaces.
+	 *
+	 * @rationale
+	 * An empty interface is equivalent to its supertype (or `{}`).
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'no-empty-interface'?: any[],
+	/**
+	 * Disallows empty blocks.
+	 *
+	 * Blocks with a comment inside are not considered empty.
+	 *
+	 * @rationale
+	 * Empty blocks are often indicators of missing code.
+	 *
+	 * @options
+	 * If `allow-empty-catch` is specified, then catch blocks are allowed to be empty.
+	 * If `allow-empty-functions` is specified, then function definitions are allowed to be empty.
+	 *
+	 * @example
+	 * "no-empty": true
+	 * "no-empty": [true,"allow-empty-catch"]
+	 * "no-empty": [true,"allow-empty-functions"]
+	 * "no-empty": [true,"allow-empty-catch","allow-empty-functions"]
+	 *
+	 * @type functionality
+	 */
+	'no-empty'?: ("allow-empty-catch" | "allow-empty-functions")[],
+	/**
+	 * Disallows `eval` function invocations.
+	 *
+	 * @rationale
+	 * `eval()` is dangerous as it allows arbitrary code execution with full privileges. There are
+	 * [alternatives](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval)
+	 * for most of the use cases for `eval()`.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-eval": true
+	 *
+	 * @type functionality
+	 */
+	'no-eval'?: any[],
+	/**
+	 * Promises returned by functions must be handled appropriately.
+	 *
+	 * Unhandled Promises can cause unexpected behavior, such as resolving at unexpected times.
+	 *
+	 * @rationale
+	 * Creating a Promise and not storing or returning it may let other code run independently of its result.
+	 * This can cause unexpected and/or non-deterministic behavior depending on external timing factors.
+	 * 
+	 * It's typically better to return Promises from functions that start them, then handle them in calling code.
+	 * 
+	 * Use `no-unused-expression` in addition to this rule to reveal even more floating promises.
+	 *
+	 * @options
+	 * A list of 'string' names of any additional classes that should also be handled as Promises.
+	 *
+	 * @example
+	 * "no-floating-promises": true
+	 * "no-floating-promises": [true,"JQueryPromise"]
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'no-floating-promises'?: unknown,
+	/**
+	 * Disallows iterating over an array with a for-in loop.
+	 *
+	 * A for-in loop (`for (var k in o)`) iterates over the properties of an Object.
+	 * 
+	 * While it is legal to use for-in loops with array types, it is not common.
+	 * for-in will iterate over the indices of the array as strings, omitting any "holes" in
+	 * the array.
+	 * 
+	 * More common is to use for-of, which iterates over the values of an array.
+	 * If you want to iterate over the indices, alternatives include:
+	 * 
+	 * array.forEach((value, index) => { ... });
+	 * for (const [index, value] of array.entries()) { ... }
+	 * for (let i = 0; i < array.length; i++) { ... }
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-for-in-array": true
+	 *
+	 * @type functionality
+	 */
+	'no-for-in-array'?: any[],
+	/**
+	 * Ban the usage of for...in statements.
+	 *
+	 * @rationale
+	 * for...in statements are legacy JavaScript syntax which usually require a verbose `hasOwnProperty` check inside their loop body. These statements can be fully replaced with for...of statements in modern JS & TS.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-for-in": true
+	 *
+	 * @type typescript
+	 */
+	'no-for-in'?: any[],
+	/**
+	 * Disallows importing modules that are not listed as dependency in the project's package.json
+	 *
+	 * Disallows importing transient dependencies and modules installed above your package's root directory.
+	 *
+	 * @options
+	 * By default the rule looks at `"dependencies"` and `"peerDependencies"`.
+	 * By adding the `"dev"` option the rule also looks at `"devDependencies"`.
+	 * By adding the `"optional"` option the rule also looks at `"optionalDependencies"`.
+	 * An array of whitelisted modules can be added to skip checking their existence in package.json.
+	 *
+	 * @example
+	 * "no-implicit-dependencies": true
+	 * "no-implicit-dependencies": [true,"dev"]
+	 * "no-implicit-dependencies": [true,"optional"]
+	 * "no-implicit-dependencies": [true,["src","app"]]
+	 *
+	 * @type functionality
+	 */
+	'no-implicit-dependencies'?: ["dev" | "optional", any[]],
+	/**
+	 * Avoid import statements with side-effect.
+	 *
+	 * @rationale
+	 * Imports with side effects may have behavior which is hard for static verification.
+	 *
+	 * @options
+	 * One argument may be optionally provided:
+	 * 
+	 * * `ignore-module` allows to specify a regex and ignore modules which it matches.
+	 *
+	 * @example
+	 * "no-import-side-effect": true
+	 * "no-import-side-effect": [true,{"ignore-module":"(\\.html|\\.css)$"}]
+	 *
+	 * @type typescript
+	 */
+	'no-import-side-effect'?: ({
+		'ignore-module'?: string,
+	})[],
+	/**
+	 * Disallows explicit type declarations for variables or parameters initialized to a number, string, or boolean.
+	 *
+	 * @rationale
+	 * Explicit types where they can be easily inferred by the compiler make code more verbose.
+	 *
+	 * @options
+	 * Two arguments may be optionally provided:
+	 * 
+	 * * `ignore-params` allows specifying an inferrable type annotation for function params.
+	 * This can be useful when combining with the `typedef` rule.
+	 * * `ignore-properties` allows specifying an inferrable type annotation for class properties.
+	 *
+	 * @example
+	 * "no-inferrable-types": true
+	 * "no-inferrable-types": [true,"ignore-params"]
+	 * "no-inferrable-types": [true,"ignore-params","ignore-properties"]
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'no-inferrable-types'?: ("ignore-params" | "ignore-properties")[],
+	/**
+	 * Disallow type inference of {} (empty object type) at function and constructor call sites
+	 *
+	 * @rationale
+	 * Prior to TypeScript 3.4, generic type parameters for functions and constructors are inferred as
+	 * `{}` (the empty object type) by default when no type parameter is explicitly supplied or when
+	 * the compiler cannot infer a more specific type.
+	 * This is often undesirable as the call is meant to be of a more specific type.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-inferred-empty-object-type": true
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'no-inferred-empty-object-type'?: any[],
+	/**
+	 * Disallows internal `module`
+	 *
+	 * @rationale
+	 * Using `module` leads to a confusion of concepts with external modules. Use the newer `namespace` keyword instead.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-internal-module": true
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'no-internal-module'?: any[],
+	/**
+	 * Warns on use of `${` in non-template strings.
+	 *
+	 * @rationale
+	 * Interpolation will only work for template strings.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-invalid-template-strings": true
+	 *
+	 * @type functionality
+	 */
+	'no-invalid-template-strings'?: any[],
+	/**
+	 * Disallows using the `this` keyword outside of classes.
+	 *
+	 * @rationale
+	 * See [the rule's author's rationale here.](https://github.com/palantir/tslint/pull/1105#issue-147549402)
+	 *
+	 * @options
+	 * One argument may be optionally provided:
+	 * 
+	 * * `check-function-in-method` disallows using the `this` keyword in functions within class methods.
+	 *
+	 * @example
+	 * "no-invalid-this": true
+	 * "no-invalid-this": [true,"check-function-in-method"]
+	 *
+	 * @type functionality
+	 */
+	'no-invalid-this'?: ("check-function-in-method")[],
+	/**
+	 * Disallow irregular whitespace within a file, including strings and comments.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-irregular-whitespace": true
+	 *
+	 * @type formatting
+	 */
+	'no-irregular-whitespace'?: any[],
+	/**
+	 * Disallows the use constant number values outside of variable assignments.
+	 * When no list of allowed values is specified, -1, 0 and 1 are allowed by default.
+	 *
+	 * @rationale
+	 * Magic numbers should be avoided as they often lack documentation.
+	 * Forcing them to be stored in variables gives them implicit documentation.
+	 *
+	 * @options
+	 * Options may either be a list of numbers to ignore (not consider 'magic'), or an object containing up to two properties:
+	 * * `allowed-numbers` as the list of numbers to ignore.
+	 * * `ignore-jsx` to specify that 'magic' numbers should be allowed as JSX attributes.
+	 *
+	 * @example
+	 * "no-magic-numbers": [true,1,2,3]
+	 * "no-magic-numbers": [true,{"allowed-numbers":[1,2,3],"ignore-jsx":true}]
+	 *
+	 * @type typescript
+	 */
+	'no-magic-numbers'?: {
+		type?: { [key: string]: unknown },
+		'allowed-numbers'?: any[],
+		'ignore-jsx'?: boolean,
+	},
+	/**
+	 * Disallows mergeable namespaces in the same file.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-mergeable-namespace": true
+	 *
+	 * @type maintainability
+	 *
+	 * @typescriptOnly
+	 */
+	'no-mergeable-namespace'?: any[],
+	/**
+	 * Warns on apparent attempts to define constructors for interfaces or `new` for classes.
+	 *
+	 * @rationale
+	 * Interfaces in TypeScript aren't meant to describe constructors on their implementations.
+	 * The `new` descriptor is primarily for describing JavaScript libraries.
+	 * If you're trying to describe a function known to be a class, it's typically better to `declare class`.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-misused-new": true
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'no-misused-new'?: any[],
+	/**
+	 * Disallows use of internal `module`s and `namespace`s.
+	 *
+	 * This rule still allows the use of `declare module ... {}`
+	 *
+	 * @rationale
+	 * ES6-style external modules are the standard way to modularize code.
+	 * Using `module {}` and `namespace {}` are outdated ways to organize TypeScript code.
+	 *
+	 * @options
+	 * One argument may be optionally provided:
+	 * 
+	 * * `allow-declarations` allows `declare namespace ... {}` to describe external APIs.
+	 *
+	 * @example
+	 * "no-namespace": true
+	 * "no-namespace": [true,"allow-declarations"]
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'no-namespace'?: ("allow-declarations")[],
+	/**
+	 * Disallows non-null assertions using the `!` postfix operator.
+	 *
+	 * @rationale
+	 * Using non-null assertion cancels the benefits of the strict null checking mode.
+	 * 
+	 * Instead of assuming objects exist:
+	 * 
+	 * ```
+	 * function foo(instance: MyClass | undefined) {
+	 *     instance!.doWork();
+	 * }
+	 * ```
+	 * 
+	 * Either inform the strict type system that the object must exist:
+	 * 
+	 * ```
+	 * function foo(instance: MyClass) {
+	 *     instance.doWork();
+	 * }
+	 * ```
+	 * 
+	 * Or verify that the instance exists, which will inform the type checker:
+	 * 
+	 * ```
+	 * function foo(instance: MyClass | undefined) {
+	 *     if (instance !== undefined) {
+	 *         instance.doWork();
+	 *     }
+	 * }
+	 * ```
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-non-null-assertion": true
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'no-non-null-assertion'?: any[],
+	/**
+	 * Disallows use of the `null` keyword literal.
+	 *
+	 * @rationale
+	 * Instead of having the dual concepts of `null` and`undefined` in a codebase,
+	 * this rule ensures that only `undefined` is used.
+	 * 
+	 * JavaScript originally intended `undefined` to refer to a value that doesn't yet exist,
+	 * while `null` was meant to refer to a value that does exist but points to nothing.
+	 * That's confusing.
+	 * `undefined` is the default value when object members don't exist, and is the return value
+	 * for newer native collection APIs such as `Map.get` when collection values don't exist.
+	 * 
+	 * ```
+	 * const myObject = {};
+	 * myObject.doesNotExist; // undefined
+	 * ```
+	 * 
+	 * ```
+	 * const myMap = new Map<string, number>();
+	 * myMap.get("doesNotExist"); // undefined
+	 * ```
+	 * 
+	 * To remove confusion over the two similar values, it's better to stick with just `undefined`.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-null-keyword": true
+	 *
+	 * @type functionality
+	 */
+	'no-null-keyword'?: any[],
+	/**
+	 * Disallows explicitly declared or implicitly returned union types with both `null` and
+	 * `undefined` as members.
+	 *
+	 * @rationale
+	 * A union type that includes both `null` and `undefined` is either redundant or fragile.
+	 * Enforcing the choice between the two allows the `triple-equals` rule to exist without
+	 * exceptions, and is essentially a more flexible version of the `no-null-keyword` rule.
+	 * Optional parameters are not considered to have the type `undefined`.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-null-undefined-union": true
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'no-null-undefined-union'?: any[],
+	/**
+	 * Forbids an object literal to appear in a type assertion expression.
+	 * Casting to `any` or to `unknown` is still allowed.
+	 *
+	 * @rationale
+	 * Always prefer `const x: T = { ... };` to `const x = { ... } as T;`.
+	 * The type assertion in the latter case is either unnecessary or hides an error.
+	 * The compiler will warn for excess properties with this syntax, but not missing required fields.
+	 * For example: `const x: { foo: number } = {}` will fail to compile, but
+	 * `const x = {} as { foo: number }` will succeed.
+	 * Additionally, the const assertion `const x = { foo: 1 } as const`,
+	 * introduced in TypeScript 3.4, is considered beneficial and is ignored by this rule.
+	 *
+	 * @options
+	 * One option may be configured:
+	 * 
+	 * * `allow-arguments` allows type assertions to be used on object literals inside call expressions.
+	 *
+	 * @example
+	 * "no-object-literal-type-assertion": true
+	 * "no-object-literal-type-assertion": [true,{"allow-arguments":true}]
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'no-object-literal-type-assertion'?: {
+		'allow-arguments'?: boolean,
+	},
+	/**
+	 * Disallows parameter properties in class constructors.
+	 *
+	 * @rationale
+	 * Parameter properties can be confusing to those new to TS as they are less explicit
+	 * than other ways of declaring and initializing class members.
+	 * 
+	 * It can be cleaner to keep member variable declarations in one list directly above the class constructor
+	 * (instead of mixed between direct class members and constructor parameter properties).
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-parameter-properties": true
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'no-parameter-properties'?: any[],
+	/**
+	 * Disallows reassigning parameters.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-parameter-reassignment": true
+	 *
+	 * @type typescript
+	 */
+	'no-parameter-reassignment'?: any[],
+	/**
+	 * Warns for Promises that are used for boolean conditions.
+	 *
+	 * For the most accurate findings, set `"strict": true` in your `tsconfig.json`.
+	 * 
+	 * It's recommended to enable the following rules as well:
+	 * * [`strict-boolean-expressions`](https://palantir.github.io/tslint/rules/strict-boolean-expressions/)
+	 * * [`strict-type-predicates`](https://palantir.github.io/tslint/rules/strict-type-predicates/)
+	 * * [`no-floating-promises`](https://palantir.github.io/tslint/rules/no-floating-promises/)
+	 *
+	 * @rationale
+	 * There are no situations where one would like to check whether a variable's value is truthy if its type
+	 * only is Promise.
+	 * This may only occur when the typings are incorrect or the variable has a union type
+	 * (like Promise | undefined), of which the latter is allowed.
+	 * 
+	 * This rule prevents common bugs from forgetting to 'await' a Promise.
+	 *
+	 * @options
+	 * A list of 'string' names of any additional classes that should also be treated as Promises.
+	 * For example, if you are using a class called 'Future' that implements the Thenable interface,
+	 * you might tell the rule to consider type references with the name 'Future' as valid Promise-like
+	 * types. Note that this rule doesn't check for type assignability or compatibility; it just checks
+	 * type reference names.
+	 *
+	 * @example
+	 * "no-promise-as-boolean": true
+	 * "no-promise-as-boolean": [true,{"OPTION_PROMISE_CLASSES":["Thenable"]}]
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'no-promise-as-boolean'?: {
+		'promise-classes'?: (string)[],
+	},
+	/**
+	 * Forbids JSDoc which duplicates TypeScript functionality.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-redundant-jsdoc": true
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'no-redundant-jsdoc'?: any[],
+	/**
+	 * Don't `<reference types="foo" />` if you import `foo` anyway.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'no-reference-import'?: any[],
+	/**
+	 * Disallows `/// <reference path=>` imports (use ES6-style imports instead).
+	 *
+	 * @rationale
+	 * Using `/// <reference path=>` comments to load other files is outdated.
+	 * Use ES6-style imports to reference other files.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-reference": true
+	 *
+	 * @type typescript
+	 */
+	'no-reference'?: any[],
+	/**
+	 * Disallows invocation of `require()`.
+	 *
+	 * @rationale
+	 * Prefer the newer ES6-style imports over `require()`.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-require-imports": true
+	 *
+	 * @type maintainability
+	 */
+	'no-require-imports'?: any[],
+	/**
+	 * Disallow specific global variables.
+	 *
+	 * Disallowing usage of specific global variables can be useful if you want to allow
+	 * a set of global variables by enabling an environment, but still want to disallow
+	 * some of those.
+	 *
+	 * @rationale
+	 * ```ts
+	 * function broken(evt: Event) {
+	 *     // Meant to do something with `evt` but typed it incorrectly.
+	 *     Event.target;  // compiler error
+	 *     event.target;  // should be a lint failure
+	 * }
+	 * 
+	 * Early Internet Explorer versions exposed the current DOM event as a global variable 'event',
+	 * but using this variable has been considered a bad practice for a long time.
+	 * Restricting this will make sure this variable isn’t used in browser code.
+	 * ```
+	 *
+	 * @options
+	 * This rule takes a list of strings, where each string is a global to be restricted.
+	 * `event`, `name` and `length` are restricted by default.
+	 *
+	 * @example
+	 * "no-restricted-globals": [true,"name","length","event"]
+	 *
+	 * @type functionality
+	 */
+	'no-restricted-globals'?: unknown,
+	/**
+	 * Disallows unnecessary `return await`.
+	 *
+	 * @rationale
+	 * An async function always wraps the return value in a Promise.
+	 * Using `return await` just adds extra time before the overreaching promise is resolved without changing the semantics.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-return-await": true
+	 *
+	 * @type functionality
+	 */
+	'no-return-await'?: any[],
+	/**
+	 * Disallows shadowing variable declarations.
+	 *
+	 * @rationale
+	 * When a variable in a local scope and a variable in the containing scope have the same name, shadowing occurs.
+	 * Shadowing makes it impossible to access the variable in the containing scope and
+	 * obscures to what value an identifier actually refers. Compare the following snippets:
+	 * 
+	 * ```
+	 * const a = 'no shadow';
+	 * function print() {
+	 *     console.log(a);
+	 * }
+	 * print(); // logs 'no shadow'.
+	 * ```
+	 * 
+	 * ```
+	 * const a = 'no shadow';
+	 * function print() {
+	 *     const a = 'shadow'; // TSLint will complain here.
+	 *     console.log(a);
+	 * }
+	 * print(); // logs 'shadow'.
+	 * ```
+	 * 
+	 * ESLint has [an equivalent rule](https://eslint.org/docs/rules/no-shadow).
+	 * For more background information, refer to
+	 * [this MDN closure doc](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures#Lexical_scoping).
+	 *
+	 * @options
+	 * You can optionally pass an object to disable checking for certain kinds of declarations.
+	 * Possible keys are `"class"`, `"enum"`, `"function"`, `"import"`, `"interface"`, `"namespace"`, `"typeAlias"`
+	 * and `"typeParameter"`. You can also pass `"underscore`" to ignore variable names that begin with `_`.
+	 * Just set the value to `false` for the check you want to disable.
+	 * All checks default to `true`, i.e. are enabled by default.
+	 * Note that you cannot disable variables and parameters.
+	 * 
+	 * The option `"temporalDeadZone"` defaults to `true` which shows errors when shadowing block scoped declarations in their
+	 * temporal dead zone. When set to `false` parameters, classes, enums and variables declared
+	 * with `let` or `const` are not considered shadowed if the shadowing occurs within their
+	 * [temporal dead zone](http://jsrocks.org/2015/01/temporal-dead-zone-tdz-demystified).
+	 * 
+	 * The following example shows how the `"temporalDeadZone"` option changes the linting result:
+	 * 
+	 * ```ts
+	 * function fn(value) {
+	 *     if (value) {
+	 *         const tmp = value; // no error on this line if "temporalDeadZone" is false
+	 *         return tmp;
+	 *     }
+	 *     let tmp = undefined;
+	 *     if (!value) {
+	 *         const tmp = value; // this line always contains an error
+	 *         return tmp;
+	 *     }
+	 * }
+	 * ```
+	 *
+	 * @example
+	 * "no-shadowed-variable": true
+	 * "no-shadowed-variable": [true,{"class":true,"enum":true,"function":true,"interface":false,"namespace":true,"typeAlias":false,"typeParameter":false,"underscore":false}]
+	 *
+	 * @type functionality
+	 */
+	'no-shadowed-variable'?: {
+		class?: boolean,
+		enum?: boolean,
+		function?: boolean,
+		import?: boolean,
+		interface?: boolean,
+		namespace?: boolean,
+		typeAlias?: boolean,
+		typeParameter?: boolean,
+		temporalDeadZone?: boolean,
+		underscore?: boolean,
+	},
+	/**
+	 * Forbids array literals to contain missing elements.
+	 *
+	 * @rationale
+	 * Missing elements are probably an accidentally duplicated comma.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-sparse-arrays": true
+	 *
+	 * @type functionality
+	 */
+	'no-sparse-arrays'?: any[],
+	/**
+	 * Forbids unnecessary string literal property access.
+	 * Allows `obj["prop-erty"]` (can't be a regular property access).
+	 * Disallows `obj["property"]` (should be `obj.property`).
+	 *
+	 * @rationale
+	 * If `--noImplicitAny` is turned off,
+	 * property access via a string literal will be 'any' if the property does not exist.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-string-literal": true
+	 *
+	 * @type functionality
+	 */
+	'no-string-literal'?: any[],
+	/**
+	 * Flags throwing plain strings or concatenations of strings.
+	 *
+	 * @rationale
+	 * Example – Doing it right
+	 * 
+	 * ```ts
+	 * // throwing an Error from typical function, whether sync or async
+	 * if (!productToAdd) {
+	 *     throw new Error("How can I add new product when no value provided?");
+	 * }
+	 * ```
+	 * 
+	 * Example – Anti Pattern
+	 * 
+	 * ```ts
+	 * // throwing a string lacks any stack trace information and other important data properties
+	 * if (!productToAdd) {
+	 *     throw ("How can I add new product when no value provided?");
+	 * }
+	 * ```
+	 * 
+	 * Only Error objects contain a `.stack` member equivalent to the current stack trace.
+	 * Primitives such as strings do not.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-string-throw": true
+	 *
+	 * @type functionality
+	 */
+	'no-string-throw'?: any[],
+	/**
+	 * Disallows importing any submodule.
+	 *
+	 * @rationale
+	 * Submodules of some packages are treated as private APIs and the import
+	 * paths may change without deprecation periods. It's best to stick with
+	 * top-level package exports.
+	 *
+	 * @options
+	 * A list of whitelisted package or submodule names.
+	 *
+	 * @example
+	 * "no-submodule-imports": true
+	 * "no-submodule-imports": [true,"rxjs","@angular/platform-browser","@angular/core/testing"]
+	 *
+	 * @type functionality
+	 */
+	'no-submodule-imports'?: (string)[],
+	/**
+	 * Disallows falling through case statements.
+	 *
+	 * For example, the following is not allowed:
+	 * 
+	 * ```ts
+	 * switch(foo) {
+	 *     case 1:
+	 *         someFunc(foo);
+	 *     case 2:
+	 *         someOtherFunc(foo);
+	 * }
+	 * ```
+	 * 
+	 * However, fall through is allowed when case statements are consecutive or
+	 * a magic `/* falls through * /` comment is present. The following is valid:
+	 * 
+	 * ```ts
+	 * switch(foo) {
+	 *     case 1:
+	 *         someFunc(foo);
+	 *         /* falls through * /
+	 *     case 2:
+	 *     case 3:
+	 *         someOtherFunc(foo);
+	 * }
+	 * ```
+	 *
+	 * @rationale
+	 * Fall though in switch statements is often unintentional and a bug.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-switch-case-fall-through": true
+	 *
+	 * @type functionality
+	 */
+	'no-switch-case-fall-through'?: any[],
+	/**
+	 * Enforces that relational/equality binary operators does not take two equal variables/literals as operands.
+	 * Expression like 3 === 3, someVar === someVar, "1" > "1" are either a tautology or contradiction, and will produce an error.
+	 *
+	 * @rationale
+	 * Clean redundant code and unnecessary comparison of objects and literals.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-tautology-expression": true
+	 *
+	 * @type functionality
+	 */
+	'no-tautology-expression'?: any[],
+	/**
+	 * Disallows unnecessary references to `this`.
+	 *
+	 * @rationale
+	 * Assigning a variable to `this` instead of properly using arrow lambdas may be a symptom of pre-ES6 practices
+	 * or not managing scope well.
+	 * 
+	 * Instead of storing a reference to `this` and using it inside a `function () {`:
+	 * 
+	 * ```
+	 * const self = this;
+	 * 
+	 * setTimeout(function () {
+	 *     self.doWork();
+	 * });
+	 * ```
+	 * 
+	 * Use `() =>` arrow lambdas, as they preserve `this` scope for you:
+	 * 
+	 * ```
+	 * setTimeout(() => {
+	 *     this.doWork();
+	 * });
+	 * ```
+	 *
+	 * @options
+	 * Two options may be provided on an object:
+	 * 
+	 * * `allow-destructuring` allows using destructuring to access members of `this` (e.g. `{ foo, bar } = this;`).
+	 * * `allowed-names` may be specified as a list of regular expressions to match allowed variable names.
+	 *
+	 * @example
+	 * "no-this-assignment": true
+	 * "no-this-assignment": [true,{"allowed-names":["^self$"],"allow-destructuring":true}]
+	 *
+	 * @type functionality
+	 */
+	'no-this-assignment'?: {
+		'allow-destructuring'?: boolean,
+		'allowed-names'?: unknown,
+	},
+	/**
+	 * Disallows trailing whitespace at the end of a line.
+	 *
+	 * @rationale
+	 * Keeps version control diffs clean as it prevents accidental whitespace from being committed.
+	 *
+	 * @options
+	 * Possible settings are:
+	 * 
+	 * * `"ignore-template-strings"`: Allows trailing whitespace in template strings.
+	 * * `"ignore-comments"`: Allows trailing whitespace in comments.
+	 * * `"ignore-jsdoc"`: Allows trailing whitespace only in JSDoc comments.
+	 * * `"ignore-blank-lines"`: Allows trailing whitespace on empty lines.
+	 *
+	 * @example
+	 * "no-trailing-whitespace": true
+	 * "no-trailing-whitespace": [true,"ignore-comments"]
+	 * "no-trailing-whitespace": [true,"ignore-jsdoc"]
+	 *
+	 * @type formatting
+	 */
+	'no-trailing-whitespace'?: ("ignore-comments" | "ignore-jsdoc" | "ignore-template-strings" | "ignore-blank-lines")[],
+	/**
+	 * Warns when a method is used outside of a method call.
+	 *
+	 * @rationale
+	 * Class functions don't preserve the class scope when passed as standalone variables.
+	 * For example, this code will log the global scope (`window`/`global`), not the class instance:
+	 * 
+	 * ```
+	 * class MyClass {
+	 *     public log(): void {
+	 *         console.log(this);
+	 *     }
+	 * }
+	 * 
+	 * const instance = new MyClass();
+	 * const log = instance.log;
+	 * 
+	 * log();
+	 * ```
+	 * 
+	 * You need to either use an arrow lambda (`() => {...}`) or call the function with the correct scope.
+	 * 
+	 * ```
+	 * class MyClass {
+	 *     public logArrowBound = (): void => {
+	 *         console.log(bound);
+	 *     };
+	 * 
+	 *     public logManualBind(): void {
+	 *         console.log(this);
+	 *     }
+	 * }
+	 * 
+	 * const instance = new MyClass();
+	 * const logArrowBound = instance.logArrowBound;
+	 * const logManualBind = instance.logManualBind.bind(instance);
+	 * 
+	 * logArrowBound();
+	 * logManualBind();
+	 * ```
+	 *
+	 * @options
+	 * You may additionally pass "ignore-static" to ignore static methods, or an options object.
+	 * 
+	 *  The object may have the following properties:
+	 * 
+	 * * "ignore-static" - to ignore static methods.
+	 * * "allow-delete" - ignore methods referenced in a delete expression.
+	 * * "allow-typeof" - ignore methods referenced in a typeof expression.
+	 * * "whitelist" - ignore method references in parameters of specifed function calls.
+	 *
+	 * @example
+	 * "no-unbound-method": true
+	 * "no-unbound-method": [true,"ignore-static"]
+	 * "no-unbound-method": [true,{"ignore-static":true,"whitelist":["expect"],"allow-typeof":true}]
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'no-unbound-method'?: "ignore-static" | {
+		'allow-delete'?: boolean,
+		'allow-typeof'?: boolean,
+		'ignore-static'?: boolean,
+		whitelist?: (string)[],
+	},
+	/**
+	 * Replaces `x => f(x)` with just `f`.
+	 * To catch more cases, enable `only-arrow-functions` and `arrow-return-shorthand` too.
+	 *
+	 * @rationale
+	 * There's generally no reason to wrap a function with a callback wrapper if it's directly called anyway.
+	 * Doing so creates extra inline lambdas that slow the runtime down.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-unnecessary-callback-wrapper": true
+	 *
+	 * @type style
+	 */
+	'no-unnecessary-callback-wrapper'?: any[],
+	/**
+	 * Disallows classes that are not strictly necessary.
+	 *
+	 * @rationale
+	 * Users who come from a Java-style OO language may wrap
+	 * their utility functions in an extra class, instead of
+	 * putting them at the top level.
+	 *
+	 * @options
+	 * Three arguments may be optionally provided:
+	 * 
+	 * * `"allow-constructor-only"` ignores classes whose members are constructors.
+	 * * `"allow-empty-class"` ignores `class DemoClass {}`.
+	 * * `"allow-static-only"` ignores classes whose members are static.
+	 *
+	 * @example
+	 * "no-unnecessary-class": true
+	 * "no-unnecessary-class": ["allow-empty-class","allow-constructor-only"]
+	 *
+	 * @type functionality
+	 */
+	'no-unnecessary-class'?: (string)[],
+	/**
+	 * Forbids a 'var'/'let' statement or destructuring initializer to be initialized to 'undefined'.
+	 *
+	 * @rationale
+	 * Values in JavaScript default to `undefined`.
+	 * There's no need to do so manually.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-unnecessary-initializer": true
+	 *
+	 * @type style
+	 */
+	'no-unnecessary-initializer'?: any[],
+	/**
+	 * Warns when a namespace qualifier (`A.x`) is unnecessary.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-unnecessary-qualifier": true
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'no-unnecessary-qualifier'?: any[],
+	/**
+	 * Warns if a type assertion does not change the type of an expression.
+	 *
+	 * @options
+	 * A list of whitelisted assertion types to ignore
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'no-unnecessary-type-assertion'?: unknown,
+	/**
+	 * Warns when using an expression of type 'any' in a dynamic way.
+	 * Uses are only allowed if they would work for `{} | null | undefined`.
+	 * Downcasting to unknown is always safe.
+	 * Type casts and tests are allowed.
+	 * Expressions that work on all values (such as `"" + x`) are allowed.
+	 *
+	 * @rationale
+	 * If you're dealing with data of unknown or "any" types, you shouldn't be accessing members of it.
+	 * Either add type annotations for properties that may exist or change the data type to the empty object type `{}`.
+	 * 
+	 * Alternately, if you're creating storage or handling for consistent but unknown types, such as in data structures
+	 * or serialization, use `<T>` template types for generic type handling.
+	 * 
+	 * Also see the `no-any` rule.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-unsafe-any": true
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'no-unsafe-any'?: any[],
+	/**
+	 * Disallows control flow statements, such as `return`, `continue`,
+	 * `break` and `throws` in finally blocks.
+	 *
+	 * @rationale
+	 * When used inside `finally` blocks, control flow statements,
+	 * such as `return`, `continue`, `break` and `throws`
+	 * override any other control flow statements in the same try/catch scope.
+	 * This is confusing and unexpected behavior.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-unsafe-finally": true
+	 *
+	 * @type functionality
+	 */
+	'no-unsafe-finally'?: any[],
+	/**
+	 * Disallows unused expression statements.
+	 *
+	 * Unused expressions are expression statements which are not assignments or function calls
+	 * (and thus usually no-ops).
+	 *
+	 * @rationale
+	 * Detects potential errors where an assignment or function call was intended.
+	 *
+	 * @options
+	 * Three arguments may be optionally provided:
+	 * 
+	 * * `allow-fast-null-checks` allows to use logical operators to perform fast null checks and perform
+	 * method or function calls for side effects (e.g. `e && e.preventDefault()`).
+	 * * `allow-new` allows 'new' expressions for side effects (e.g. `new ModifyGlobalState();`.
+	 * * `allow-tagged-template` allows tagged templates for side effects (e.g. `this.add\`foo\`;`.
+	 *
+	 * @example
+	 * "no-unused-expression": true
+	 * "no-unused-expression": [true,"allow-fast-null-checks"]
+	 *
+	 * @type functionality
+	 */
+	'no-unused-expression'?: ("allow-fast-null-checks" | "allow-new" | "allow-tagged-template")[],
+	/**
+	 * Disallows unused imports, variables, functions and
+	 * private class members. Similar to tsc's --noUnusedParameters and --noUnusedLocals
+	 * options, but does not interrupt code compilation.
+	 *
+	 * In addition to avoiding compilation errors, this rule may still be useful if you
+	 * wish to have `tslint` automatically remove unused imports, variables, functions,
+	 * and private class members, when using TSLint's `--fix` option.
+	 *
+	 * @rationale
+	 * Variables that are declared and not used anywhere in code are likely an error due to incomplete refactoring.
+	 * Such variables take up space in the code, are mild performance pains, and can lead to confusion by readers.
+	 *
+	 * @options
+	 * Two optional arguments may be optionally provided:
+	 * 
+	 * * `"check-parameters"` disallows unused function and constructor parameters.
+	 *     * NOTE: this option is experimental and does not work with classes
+	 *     that use abstract method declarations, among other things.
+	 * * `{"ignore-pattern": "pattern"}` where pattern is a case-sensitive regexp.
+	 * Variable names and imports that match the pattern will be ignored.
+	 *
+	 * @example
+	 * "no-unused-variable": true
+	 * "no-unused-variable": [true,{"ignore-pattern":"^_"}]
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'no-unused-variable'?: ("check-parameters" | {
+		'ignore-pattern'?: string,
+	})[],
+	/**
+	 * Disallows usage of variables before their declaration.
+	 *
+	 * This rule is primarily useful when using the `var` keyword since the compiler will
+	 * automatically detect if a block-scoped `let` and `const` variable is used before
+	 * declaration. Since most modern TypeScript doesn't use `var`, this rule is generally
+	 * discouraged and is kept around for legacy purposes. It is slow to compute, is not
+	 * enabled in the built-in configuration presets, and should not be used to inform TSLint
+	 * design decisions.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-use-before-declare": true
+	 *
+	 * @type functionality
+	 */
+	'no-use-before-declare'?: any[],
+	/**
+	 * Disallows usage of the `var` keyword.
+	 *
+	 * Use `let` or `const` instead.
+	 *
+	 * @rationale
+	 * Declaring variables using `var` has several edge case behaviors that make `var` unsuitable for modern code.
+	 * Variables declared by `var` have their parent function block as their scope, ignoring other control flow statements.
+	 * `var`s have declaration "hoisting" (similar to `function`s) and can appear to be used before declaration.
+	 * 
+	 * Variables declared by `const` and `let` instead have as their scope the block in which they are defined,
+	 * and are not allowed to used before declaration or be re-declared with another `const` or `let`.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-var-keyword": true
+	 *
+	 * @type functionality
+	 */
+	'no-var-keyword'?: any[],
+	/**
+	 * Disallows the use of require statements except in import statements.
+	 *
+	 * In other words, the use of forms such as `var module = require("module")` are banned.
+	 * Instead use ES2015-style imports or `import foo = require('foo')` imports.
+	 *
+	 * @rationale
+	 * AMD-style `require([])` and CommonJS-style `require("")` statements are environment-specific
+	 * and more difficult to statically analyze.
+	 * 
+	 * ES2015-style `import`s are part of the JavaScript language specfication and recommended as the path going forward.
+	 * TypeScript will compile them to environment-specific forms as needed.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "no-var-requires": true
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'no-var-requires'?: any[],
+	/**
+	 * Requires expressions of type `void` to appear in statement position.
+	 *
+	 * @rationale
+	 * It's misleading returning the results of an expression whose type is `void`.
+	 * Attempting to do so is likely a symptom of expecting a different return type from a function.
+	 * For example, the following code will log `undefined` but looks like it logs a value:
+	 * 
+	 * ```
+	 * const performWork = (): void => {
+	 *     workFirst();
+	 *     workSecond();
+	 * };
+	 * 
+	 * console.log(performWork());
+	 * ```
+	 *
+	 * @options
+	 * If `ignore-arrow-function-shorthand` is provided, `() => returnsVoid()` will be allowed.
+	 * Otherwise, it must be written as `() => { returnsVoid(); }`.
+	 *
+	 * @type functionality
+	 */
+	'no-void-expression'?: ("ignore-arrow-function-shorthand")[],
+	/**
+	 * Checks that decimal literals should begin with '0.' instead of just '.', and should not end with a trailing '0'.
+	 *
+	 * @rationale
+	 * Helps keep a consistent style with numeric literals.
+	 * Non-standard literals are more difficult to scan through and can be a symptom of typos.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "number-literal-format": true
+	 *
+	 * @type formatting
+	 */
+	'number-literal-format'?: any[],
+	/**
+	 * Enforces consistent object literal property quote style.
+	 *
+	 * Object literal property names can be defined in two ways: using literals or using strings.
+	 * For example, these two objects are equivalent:
+	 * 
+	 * var object1 = {
+	 *     property: true
+	 * };
+	 * 
+	 * var object2 = {
+	 *     "property": true
+	 * };
+	 * 
+	 * In many cases, it doesn’t matter if you choose to use an identifier instead of a string
+	 * or vice-versa. Even so, you might decide to enforce a consistent style in your code.
+	 * 
+	 * This rules lets you enforce consistent quoting of property names. Either they should always
+	 * be quoted (default behavior) or quoted only as needed ("as-needed").
+	 *
+	 * @options
+	 * Possible settings are:
+	 * 
+	 * * `"always"`: Property names should always be quoted. (This is the default.)
+	 * * `"as-needed"`: Only property names which require quotes may be quoted (e.g. those with spaces in them).
+	 * * `"consistent"`: Property names should either all be quoted or unquoted.
+	 * * `"consistent-as-needed"`: If any property name requires quotes, then all properties must be quoted. Otherwise, no
+	 * property names may be quoted.
+	 * 
+	 * For ES6, computed property names (`{[name]: value}`) and methods (`{foo() {}}`) never need
+	 * to be quoted.
+	 *
+	 * @example
+	 * "object-literal-key-quotes": [true,"as-needed"]
+	 * "object-literal-key-quotes": [true,"always"]
+	 *
+	 * @type style
+	 */
+	'object-literal-key-quotes'?: "always" | "as-needed" | "consistent" | "consistent-as-needed",
+	/**
+	 * Enforces/disallows use of ES6 object literal shorthand.
+	 *
+	 * @options
+	 * `"always"` assumed to be default option, thus with no options provided
+	 * the rule enforces object literal methods and properties shorthands.
+	 * With `"never"` option provided, any shorthand object literal syntax causes an error.
+	 * 
+	 * The rule can be configured in a more granular way.
+	 * With `{"property": "never"}` provided (which is equivalent to `{"property": "never", "method": "always"}`),
+	 * the rule only flags property shorthand assignments,
+	 * and respectively with `{"method": "never"}` (equivalent to `{"property": "always", "method": "never"}`),
+	 * the rule fails only on method shorthands.
+	 *
+	 * @example
+	 * "object-literal-shorthand": true
+	 * "object-literal-shorthand": [true,"never"]
+	 * "object-literal-shorthand": [true,{"property":"never"}]
+	 *
+	 * @type style
+	 */
+	'object-literal-shorthand'?: "never" | {
+		property?: "never",
+		method?: "never",
+	},
+	/**
+	 * Checks ordering of keys in object literals.
+	 * 
+	 * When using the default alphabetical ordering, additional blank lines may be used to group
+	 * object properties together while keeping the elements within each group in alphabetical order.
+	 * To opt out of this use ignore-blank-lines option.
+	 *
+	 * @rationale
+	 * Useful in preventing merge conflicts
+	 *
+	 * @options
+	 * By default, this rule checks that keys are in alphabetical order.
+	 * The following may optionally be passed:
+	 * 
+	 * * `ignore-blank-lines` will enforce alphabetical ordering regardless of blank lines between each key-value pair.
+	 * * `ignore-case` will compare keys in a case insensitive way.
+	 * * `locale-compare` will compare keys using the expected sort order of special characters, such as accents.
+	 * * `match-declaration-order` will prefer to use the key ordering of the contextual type of the object literal, as in:
+	 * 
+	 *     ```
+	 *     interface I { foo: number; bar: number; }
+	 *     const obj: I = { foo: 1, bar: 2 };
+	 *     ```
+	 * 
+	 * If a contextual type is not found, alphabetical ordering will be used instead.
+	 * * "match-declaration-order-only" exactly like "match-declaration-order",
+	 *     but don't fall back to alphabetical if a contextual type is not found.
+	 * 
+	 *     Note: If both match-declaration-order-only and match-declaration-order options are present,
+	 *           match-declaration-order-only will take precedence and alphabetical fallback will not occur.
+	 * 
+	 * * `shorthand-first` will enforce shorthand properties to appear first, as in:
+	 * 
+	 *     ```
+	 *     const obj = { a, c, b: true };
+	 *     ```
+	 *
+	 * @example
+	 * "object-literal-sort-keys": true
+	 * "object-literal-sort-keys": [true,"ignore-blank-lines","ignore-case","locale-compare","match-declaration-order","shorthand-first"]
+	 *
+	 * @type maintainability
+	 */
+	'object-literal-sort-keys'?: "ignore-blank-lines" | "ignore-case" | "locale-compare" | "match-declaration-order" | "match-declaration-order-only" | "shorthand-first",
+	/**
+	 * Requires the specified tokens to be on the same line as the expression preceding them.
+	 *
+	 * @options
+	 * Five arguments may be optionally provided:
+	 * 
+	 * * `"check-catch"` checks that `catch` is on the same line as the closing brace for `try`.
+	 * * `"check-finally"` checks that `finally` is on the same line as the closing brace for `catch`.
+	 * * `"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.
+	 *
+	 * @example
+	 * "one-line": [true,"check-catch","check-finally","check-else"]
+	 *
+	 * @type style
+	 */
+	'one-line'?: ("check-catch" | "check-finally" | "check-else" | "check-open-brace" | "check-whitespace")[],
+	/**
+	 * Disallows multiple variable definitions in the same declaration statement.
+	 *
+	 * @options
+	 * One argument may be optionally provided:
+	 * 
+	 * * `ignore-for-loop` allows multiple variable definitions in a for loop declaration.
+	 *
+	 * @example
+	 * "one-variable-per-declaration": true
+	 * "one-variable-per-declaration": [true,"ignore-for-loop"]
+	 *
+	 * @type style
+	 */
+	'one-variable-per-declaration'?: ("ignore-for-loop")[],
+	/**
+	 * Disallows traditional (non-arrow) function expressions.
+	 *
+	 * Note that non-arrow functions are allowed if 'this' appears somewhere in its body
+	 * (as such functions cannot be converted to arrow functions).
+	 *
+	 * @rationale
+	 * Traditional functions don't bind lexical scope, which can lead to unexpected behavior when accessing 'this'.
+	 *
+	 * @options
+	 * Two arguments may be optionally provided:
+	 * 
+	 * * `"allow-declarations"` allows standalone function declarations.
+	 * * `"allow-named-functions"` allows the expression `function foo() {}` but not `function() {}`.
+	 *
+	 * @example
+	 * "only-arrow-functions": true
+	 * "only-arrow-functions": [true,"allow-declarations","allow-named-functions"]
+	 *
+	 * @type typescript
+	 */
+	'only-arrow-functions'?: ("allow-declarations" | "allow-named-functions")[],
+	/**
+	 * Requires that import statements be alphabetized and grouped.
+	 *
+	 * Enforce a consistent ordering for ES6 imports:
+	 * - Named imports must be alphabetized (i.e. "import {A, B, C} from "foo";")
+	 *     - The exact ordering can be controlled by the named-imports-order option.
+	 *     - "longName as name" imports are ordered by "longName".
+	 * - Import sources must be alphabetized within groups, i.e.:
+	 *         import * as foo from "a";
+	 *         import * as bar from "b";
+	 * - Groups of imports are delineated by blank lines. You can use this rule to group
+	 *     imports however you like, e.g. by first- vs. third-party or thematically or
+	 *     you can define groups based upon patterns in import path names.
+	 *
+	 * @options
+	 * You may set the `"import-sources-order"` option to control the ordering of source
+	 * imports (the `"foo"` in `import {A, B, C} from "foo"`).
+	 * 
+	 * Possible values for `"import-sources-order"` are:
+	 * 
+	 * * `"case-insensitive'`: Correct order is `"Bar"`, `"baz"`, `"Foo"`. (This is the default.)
+	 * * `"case-insensitive-legacy'`: Correct order is `"Bar"`, `"baz"`, `"Foo"`.
+	 * * `"lowercase-first"`: Correct order is `"baz"`, `"Bar"`, `"Foo"`.
+	 * * `"lowercase-last"`: Correct order is `"Bar"`, `"Foo"`, `"baz"`.
+	 * * `"any"`: Allow any order.
+	 * 
+	 * You may set the `"grouped-imports"` option to control the grouping of source
+	 * imports (the `"foo"` in `import {A, B, C} from "foo"`).  The grouping used
+	 * is controlled by the `"groups"` option.
+	 * 
+	 * Possible values for `"grouped-imports"` are:
+	 * 
+	 * * `false`: Do not enforce grouping. (This is the default.)
+	 * * `true`: Group source imports using default grouping or groups setting.
+	 * 
+	 * The value of `"groups"` is a list of group rules of the form:
+	 * 
+	 *     [{
+	 *         "name": "optional rule name",
+	 *         "match": "regex string",
+	 *         "order": 10
+	 *     }, {
+	 *         "name": "pkga imports",
+	 *         "match": "^@pkga",
+	 *         "order": 20
+	 *     }]
+	 * 
+	 * there is also a simplified form where you only pass a list of patterns and
+	 * the order is given by the position in the list
+	 * 
+	 *     ["^@pkga", "^\.\."]
+	 * 
+	 * The first rule in the list to match a given import is the group that is used.
+	 * If no rule in matched then the import will be put in an `unmatched` group
+	 * at the end of all groups. The groups must be ordered based upon the sequential
+	 * value of the `order` value. (ie. order 0 is first)
+	 * 
+	 * If no `"groups"` options is set, a default grouping is used of third-party,
+	 * parent directories and the current directory. (`"bar"`, `"../baz"`, `"./foo"`.)
+	 * 
+	 * You may set the `"named-imports-order"` option to control the ordering of named
+	 * imports (the `{A, B, C}` in `import {A, B, C} from "foo"`).
+	 * 
+	 * Possible values for `"named-imports-order"` are:
+	 * 
+	 * * `"case-insensitive'`: Correct order is `{A, b, C}`. (This is the default.)
+	 * * `"case-insensitive-legacy'`: Correct order is `"Bar"`, `"baz"`, `"Foo"`.
+	 * * `"lowercase-first"`: Correct order is `{b, A, C}`.
+	 * * `"lowercase-last"`: Correct order is `{A, C, b}`.
+	 * * `"any"`: Allow any order.
+	 * 
+	 * You may set the `"module-source-path"` option to control the ordering of imports based full path
+	 * or just the module name
+	 * 
+	 * Possible values for `"module-source-path"` are:
+	 * 
+	 * * `"full'`: Correct order is  `"./a/Foo"`, `"./b/baz"`, `"./c/Bar"`. (This is the default.)
+	 * * `"basename"`: Correct order is `"./c/Bar"`, `"./b/baz"`, `"./a/Foo"`.
+	 *
+	 * @example
+	 * "ordered-imports": true
+	 * "ordered-imports": [true,{"import-sources-order":"lowercase-last","named-imports-order":"lowercase-first"}]
+	 *
+	 * @type style
+	 */
+	'ordered-imports'?: {
+		'grouped-imports'?: boolean,
+		groups?: unknown,
+		'import-sources-order'?: "case-insensitive" | "case-insensitive-legacy" | "lowercase-first" | "lowercase-last" | "any",
+		'named-imports-order'?: "case-insensitive" | "case-insensitive-legacy" | "lowercase-first" | "lowercase-last" | "any",
+		'module-source-path'?: "full" | "basename",
+	},
+	/**
+	 * Recommends to use a conditional expression instead of assigning to the same thing in each branch of an if statement.
+	 *
+	 * @rationale
+	 * This reduces duplication and can eliminate an unnecessary variable declaration.
+	 *
+	 * @options
+	 * If `check-else-if` is specified, the rule also checks nested if-else-if statements.
+	 *
+	 * @example
+	 * "prefer-conditional-expression": true
+	 * "prefer-conditional-expression": [true,"check-else-if"]
+	 *
+	 * @type functionality
+	 */
+	'prefer-conditional-expression'?: "check-else-if",
+	/**
+	 * Requires that variable declarations use `const` instead of `let` and `var` if possible.
+	 *
+	 * If a variable is only assigned to once when it is declared, it should be declared using 'const'
+	 *
+	 * @options
+	 * An optional object containing the property "destructuring" with two possible values:
+	 * 
+	 * * "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
+	 * * "all" - Only warns if all variables in destructuring can be const.
+	 *
+	 * @example
+	 * "prefer-const": true
+	 * "prefer-const": [true,{"destructuring":"all"}]
+	 *
+	 * @type maintainability
+	 */
+	'prefer-const'?: {
+		destructuring?: "all" | "any",
+	},
+	/**
+	 * Recommends a 'for-of' loop over a standard 'for' loop if the index is only used to access the array being iterated.
+	 *
+	 * @rationale
+	 * A for(... of ...) loop is easier to implement and read when the index is not needed.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "prefer-for-of": true
+	 *
+	 * @type typescript
+	 */
+	'prefer-for-of'?: any[],
+	/**
+	 * Warns for class methods that do not use 'this'.
+	 *
+	 * @options
+	 * "allow-public" excludes checking of public methods.
+	 * "allow-protected" excludes checking of protected methods.
+	 *
+	 * @example
+	 * "prefer-function-over-method": true
+	 * "prefer-function-over-method": [true,"allow-public","allow-protected"]
+	 *
+	 * @type style
+	 */
+	'prefer-function-over-method'?: "allow-public" | "allow-protected",
+	/**
+	 * Prefer `foo(): void` over `foo: () => void` in interfaces and types.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "prefer-method-signature": true
+	 *
+	 * @type style
+	 */
+	'prefer-method-signature'?: any[],
+	/**
+	 * Enforces the use of the ES2018 object spread operator over `Object.assign()` where appropriate.
+	 *
+	 * @rationale
+	 * Object spread allows for better type checking and inference.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "prefer-object-spread": true
+	 *
+	 * @type functionality
+	 */
+	'prefer-object-spread'?: any[],
+	/**
+	 * Requires that private variables are marked as `readonly` if they're never modified outside of the constructor.
+	 *
+	 * If a private variable is only assigned to in the constructor, it should be declared as `readonly`.
+	 *
+	 * @rationale
+	 * Marking never-modified variables as readonly helps enforce the code's intent of keeping them as never-modified.
+	 * It can also help prevent accidental changes of members not meant to be changed.
+	 *
+	 * @options
+	 * If `only-inline-lambdas` is specified, only immediately-declared arrow functions are checked.
+	 *
+	 * @example
+	 * "prefer-readonly": true
+	 * "prefer-readonly": [true,"only-inline-lambdas"]
+	 *
+	 * @type maintainability
+	 *
+	 * @typescriptOnly
+	 */
+	'prefer-readonly'?: "only-inline-lambdas",
+	/**
+	 * Prefer a `switch` statement to an `if` statement with simple `===` comparisons.
+	 *
+	 * @options
+	 * An optional object with the property 'min-cases'.
+	 * This is the number cases needed before a switch statement is recommended.
+	 * Defaults to 3.
+	 *
+	 * @example
+	 * "prefer-switch": true
+	 * "prefer-switch": [true,{"min-cases":2}]
+	 *
+	 * @type style
+	 */
+	'prefer-switch'?: {
+		'min-cases'?: number,
+	},
+	/**
+	 * Prefer a template expression over string literal concatenation.
+	 *
+	 * @options
+	 * If `allow-single-concat` is specified, then a single concatenation (`x + y`) is allowed, but not more (`x + y + z`).
+	 *
+	 * @example
+	 * "prefer-template": true
+	 * "prefer-template": [true,"allow-single-concat"]
+	 *
+	 * @type style
+	 */
+	'prefer-template'?: "allow-single-concat",
+	/**
+	 * Prefer `while` loops instead of `for` loops without an initializer and incrementor.
+	 *
+	 * @rationale
+	 * Simplifies the readability of the loop statement, while maintaining the same functionality.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "prefer-while": true
+	 *
+	 * @type style
+	 */
+	'prefer-while'?: any[],
+	/**
+	 * Requires any function or method that returns a promise to be marked async.
+	 *
+	 * @rationale
+	 * Ensures that each function is only capable of 1) returning a rejected promise, or 2)
+	 * throwing an Error object. In contrast, non-`async` `Promise`-returning functions
+	 * are technically capable of either. This practice removes a requirement for consuming
+	 * code to handle both cases.
+	 * 
+	 * If no optional arguments are provided then all function types are checked,
+	 * otherwise the specific function types are checked:
+	 * 
+	 * * `"check-function-declaration"` check function declarations.
+	 * * `"check-function-expression"` check function expressions.
+	 * * `"check-arrow-function"` check arrow functions.
+	 * * `"check-method-declaration"` check method declarations.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "promise-function-async": true
+	 * "promise-function-async": [true,"check-function-declaration","check-method-declaration"]
+	 *
+	 * @type typescript
+	 */
+	'promise-function-async'?: ("check-function-declaration" | "check-function-expression" | "check-arrow-function" | "check-method-declaration")[],
+	/**
+	 * Enforces quote character for string literals.
+	 *
+	 * @options
+	 * Five arguments may be optionally provided:
+	 * 
+	 * * `"single"` enforces single quotes.
+	 * * `"double"` enforces double quotes.
+	 * * `"backtick"` enforces backticks.
+	 * * `"jsx-single"` enforces single quotes for JSX attributes.
+	 * * `"jsx-double"` enforces double quotes for JSX attributes.
+	 * * `"avoid-template"` forbids single-line untagged template strings that do not contain string interpolations.
+	 *     Note that backticks may still be used if `"avoid-escape"` is enabled and both single and double quotes are
+	 *     present in the string (the latter option takes precedence).
+	 * * `"avoid-escape"` allows you to use the "other" quotemark in cases where escaping would normally be required.
+	 *     For example, `[true, "double", "avoid-escape"]` would not report a failure on the string literal
+	 *     `'Hello "World"'`.
+	 *
+	 * @example
+	 * "quotemark": [true,"single","avoid-escape","avoid-template"]
+	 * "quotemark": [true,"single","jsx-double"]
+	 *
+	 * @type formatting
+	 */
+	'quotemark'?: ("single" | "double" | "backtick" | "jsx-single" | "jsx-double" | "avoid-escape" | "avoid-template")[],
+	/**
+	 * Requires the radix parameter to be specified when calling `parseInt`.
+	 *
+	 * @rationale
+	 * From [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt):
+	 * > Always specify this parameter to eliminate reader confusion and to guarantee predictable behavior.
+	 * > Different implementations produce different results when a radix is not specified, usually defaulting the value to 10.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "radix": true
+	 *
+	 * @type functionality
+	 */
+	'radix'?: any[],
+	/**
+	 * When adding two variables, operands must both be of type number or of type string.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "restrict-plus-operands": true
+	 *
+	 * @type functionality
+	 */
+	'restrict-plus-operands'?: any[],
+	/**
+	 * Prefer `return;` in void functions and `return undefined;` in value-returning functions.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "return-undefined": true
+	 *
+	 * @type style
+	 */
+	'return-undefined'?: any[],
+	/**
+	 * Enforces consistent semicolon usage at the end of every statement.
+	 *
+	 * @options
+	 * One of the following arguments must be provided:
+	 * 
+	 * * `"always"` enforces semicolons at the end of every statement.
+	 * * `"never"` disallows semicolons at the end of every statement except for when they are necessary.
+	 * 
+	 * The following arguments may be optionally provided:
+	 * 
+	 * * `"ignore-interfaces"` skips checking semicolons at the end of interface members.
+	 * * `"ignore-bound-class-methods"` skips checking semicolons at the end of bound class methods.
+	 * * `"strict-bound-class-methods"` disables any special handling of bound class methods and treats them as any
+	 * other assignment. This option overrides `"ignore-bound-class-methods"`.
+	 *
+	 * @example
+	 * "semicolon": [true,"always"]
+	 * "semicolon": [true,"never"]
+	 * "semicolon": [true,"always","ignore-interfaces"]
+	 * "semicolon": [true,"always","ignore-bound-class-methods"]
+	 *
+	 * @type formatting
+	 */
+	'semicolon'?: ["always" | "never", "ignore-interfaces"],
+	/**
+	 * Require or disallow a space before function parenthesis
+	 *
+	 * @options
+	 * One argument which is an object which may contain the keys `anonymous`, `named`, and `asyncArrow`
+	 * These should be set to either `"always"` or `"never"`.
+	 * 
+	 * * `"anonymous"` checks before the opening paren in anonymous functions
+	 * * `"named"` checks before the opening paren in named functions
+	 * * `"asyncArrow"` checks before the opening paren in async arrow functions
+	 * * `"method"` checks before the opening paren in class methods
+	 * * `"constructor"` checks before the opening paren in class constructors
+	 *
+	 * @example
+	 * "space-before-function-paren": true
+	 * "space-before-function-paren": [true,"always"]
+	 * "space-before-function-paren": [true,"never"]
+	 * "space-before-function-paren": [true,{"anonymous":"always","named":"never","asyncArrow":"always"}]
+	 *
+	 * @type style
+	 */
+	'space-before-function-paren'?: {
+		anonymous?: "always" | "never",
+		asyncArrow?: "always" | "never",
+		constructor?: "always" | "never",
+		method?: "always" | "never",
+		named?: "always" | "never",
+	},
+	/**
+	 * Enforces spaces within parentheses or disallow them.  Empty parentheses () are always allowed.
+	 *
+	 * @options
+	 * You may enforce the amount of whitespace within parentheses.
+	 *
+	 * @type style
+	 */
+	'space-within-parens'?: number,
+	/**
+	 * Ban the use of `this` in static methods.
+	 *
+	 * @rationale
+	 * Static `this` usage can be confusing for newcomers.
+	 * It can also become imprecise when used with extended classes when a static `this` of a parent class no longer specifically refers to the parent class.
+	 *
+	 * @example
+	 * "static-this": true
+	 *
+	 * @type functionality
+	 */
+	'static-this'?: any[],
+	/**
+	 * Restricts the types allowed in boolean expressions. By default only booleans are allowed.
+	 * 
+	 * The following nodes are checked:
+	 * 
+	 * * Arguments to the `!`, `&&`, and `||` operators
+	 * * The condition in a conditional expression (`cond ? x : y`)
+	 * * Conditions for `if`, `for`, `while`, and `do-while` statements.
+	 *
+	 * @options
+	 * These options may be provided:
+	 * 
+	 * * `allow-null-union` allows union types containing `null`.
+	 *   - It does *not* allow `null` itself.
+	 *   - Without the '--strictNullChecks' compiler option, this will allow anything other than a string, number, or enum.
+	 * * `allow-undefined-union` allows union types containing `undefined`.
+	 *   - It does *not* allow `undefined` itself.
+	 *   - Without the '--strictNullChecks' compiler option, this will allow anything other than a string, number, or enum.
+	 * * `allow-string` allows strings.
+	 *   - It does *not* allow unions containing `string`.
+	 *   - It does *not* allow string literal types.
+	 * * `allow-enum` allows enums.
+	 *   - It does *not* allow unions containing `enum`.
+	 * * `allow-number` allows numbers.
+	 *   - It does *not* allow unions containing `number`.
+	 *   - It does *not* allow enums or number literal types.
+	 * * `allow-mix` allows multiple of the above to appear together.
+	 *   - For example, `string | number` or `RegExp | null | undefined` would normally not be allowed.
+	 *   - A type like `"foo" | "bar" | undefined` is always allowed, because it has only one way to be false.
+	 * * `allow-boolean-or-undefined` allows `boolean | undefined`.
+	 *   - Also allows `true | false | undefined`.
+	 *   - Does not allow `false | undefined`.
+	 *   - This option is a subset of `allow-undefined-union`, so you don't need to enable both options at the same time.
+	 * * `ignore-rhs` ignores the right-hand operand of `&&` and `||`.
+	 *
+	 * @example
+	 * "strict-boolean-expressions": true
+	 * "strict-boolean-expressions": [true,"allow-null-union","allow-undefined-union","allow-string","allow-enum","allow-number"]
+	 * "strict-boolean-expressions": [true,"allow-boolean-or-undefined"]
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'strict-boolean-expressions'?: ("allow-null-union" | "allow-undefined-union" | "allow-string" | "allow-enum" | "allow-number" | "allow-boolean-or-undefined" | "ignore-rhs")[],
+	/**
+	 * Only allow comparisons between primitives.
+	 *
+	 * @rationale
+	 * When using comparison operators to compare objects, they compare references and not values.
+	 * This is often done accidentally.
+	 * With this rule, `>`, `>=`, `<`, `<=` operators are only allowed when comparing `numbers`.
+	 * `===`, `!==` are allowed for `number` `string` and `boolean` types and if one of the
+	 * operands is `null` or `undefined`.
+	 *
+	 * @options
+	 * One of the following arguments may be optionally provided:
+	 * * `allow-object-equal-comparison` allows `!=` `==` `!==` `===` comparison between any types.
+	 * * `allow-string-order-comparison` allows `>` `<` `>=` `<=` comparison between strings.
+	 *
+	 * @example
+	 * "strict-comparisons": true
+	 * "strict-comparisons": [true,{"allow-object-equal-comparison":false,"allow-string-order-comparison":false}]
+	 *
+	 * @type functionality
+	 */
+	'strict-comparisons'?: {
+		'allow-object-equal-comparison'?: boolean,
+		'allow-string-order-comparison'?: boolean,
+	},
+	/**
+	 * Disable implicit toString() calls
+	 *
+	 * Require explicit toString() call for variables used in strings. By default only strings are allowed.
+	 * 
+	 * The following nodes are checked:
+	 * 
+	 * * String literals ("foo" + bar)
+	 * * ES6 templates (`foo ${bar}`)
+	 *
+	 * @options
+	 * Following arguments may be optionally provided:
+	 * * `allow-empty-types` allows `null`, `undefined` and `never` to be passed into strings without explicit conversion
+	 *
+	 * @example
+	 * "strict-string-expressions": true
+	 * "strict-string-expressions": [true,{"allow-empty-types":true}]
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'strict-string-expressions'?: {
+		'allow-empty-types'?: boolean,
+	},
+	/**
+	 * Warns for type predicates that are always true or always false.
+	 * Works for 'typeof' comparisons to constants (e.g. 'typeof foo === "string"'), and equality comparison to 'null'/'undefined'.
+	 * (TypeScript won't let you compare '1 === 2', but it has an exception for '1 === undefined'.)
+	 * Does not yet work for 'instanceof'.
+	 * Does *not* warn for 'if (x.y)' where 'x.y' is always truthy. For that, see strict-boolean-expressions.
+	 * 
+	 * This rule requires `strictNullChecks` to work properly.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "strict-type-predicates": true
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'strict-type-predicates'?: any[],
+	/**
+	 * Require a `default` case in all `switch` statements.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "switch-default": true
+	 *
+	 * @type functionality
+	 */
+	'switch-default'?: any[],
+	/**
+	 * Checks whether the final clause of a switch statement ends in `break;`.
+	 *
+	 * @options
+	 * If no options are passed, a final 'break;' is forbidden.
+	 * If the "always" option is passed this will require a 'break;' to always be present
+	 * unless control flow is escaped in some other way.
+	 *
+	 * @example
+	 * "switch-final-break": true
+	 * "switch-final-break": [true,"always"]
+	 *
+	 * @type style
+	 */
+	'switch-final-break'?: "always",
+	/**
+	 * Requires or disallows trailing commas in array and object literals, destructuring assignments, function typings,
+	 * named imports and exports and function parameters.
+	 *
+	 * @options
+	 * One argument which is an object with the keys `multiline` and `singleline`.
+	 * Both can be set to a string (`"always"` or `"never"`) or an object.
+	 * 
+	 * The object can contain any of the following keys: `"arrays"`, `"objects"`, `"functions"`,
+	 * `"imports"`, `"exports"`, and `"typeLiterals"`; each key can have one of the following
+	 * values: `"always"`, `"never"`, and `"ignore"`. Any missing keys will default to `"ignore"`.
+	 * 
+	 * * `"multiline"` checks multi-line object literals.
+	 * * `"singleline"` checks single-line object literals.
+	 * 
+	 * An array is considered "multiline" if its closing bracket is on a line
+	 * after the last array element. The same general logic is followed for
+	 * object literals, function typings, named import statements
+	 * and function parameters.
+	 * 
+	 * To align this rule with the ECMAScript specification that is implemented in modern JavaScript VMs,
+	 * there is a third option `esSpecCompliant`. Set this option to `true` to disallow trailing comma on
+	 * object and array rest and rest parameters.
+	 *
+	 * @example
+	 * "trailing-comma": [true,{"multiline":"always","singleline":"never"}]
+	 * "trailing-comma": [true,{"multiline":{"objects":"always","arrays":"always","functions":"never","typeLiterals":"ignore"},"esSpecCompliant":true}]
+	 *
+	 * @type formatting
+	 */
+	'trailing-comma'?: {
+		multiline?: "always" | "never" | {
+			arrays?: "always" | "never" | "ignore",
+			exports?: "always" | "never" | "ignore",
+			functions?: "always" | "never" | "ignore",
+			imports?: "always" | "never" | "ignore",
+			objects?: "always" | "never" | "ignore",
+			typeLiterals?: "always" | "never" | "ignore",
+		},
+		singleline?: "always" | "never" | {
+			arrays?: "always" | "never" | "ignore",
+			exports?: "always" | "never" | "ignore",
+			functions?: "always" | "never" | "ignore",
+			imports?: "always" | "never" | "ignore",
+			objects?: "always" | "never" | "ignore",
+			typeLiterals?: "always" | "never" | "ignore",
+		},
+		esSpecCompliant?: boolean,
+	},
+	/**
+	 * Requires `===` and `!==` in place of `==` and `!=`.
+	 *
+	 * @options
+	 * Two arguments may be optionally provided:
+	 * 
+	 * * `"allow-null-check"` allows `==` and `!=` when comparing to `null`.
+	 * * `"allow-undefined-check"` allows `==` and `!=` when comparing to `undefined`.
+	 *
+	 * @example
+	 * "triple-equals": true
+	 * "triple-equals": [true,"allow-null-check"]
+	 * "triple-equals": [true,"allow-undefined-check"]
+	 *
+	 * @type functionality
+	 */
+	'triple-equals'?: ("allow-null-check" | "allow-undefined-check")[],
+	/**
+	 * Checks that type literal members are separated by semicolons.
+	 * Enforces a trailing semicolon for multiline type literals.
+	 *
+	 * @options
+	 * `{singleLine: "always"}` enforces semicolon for one liners
+	 *
+	 * @example
+	 * "type-literal-delimiter": true
+	 *
+	 * @type style
+	 *
+	 * @typescriptOnly
+	 */
+	'type-literal-delimiter'?: {
+		singleLine?: "always" | "never",
+	},
+	/**
+	 * Requires type definitions to exist.
+	 *
+	 * @options
+	 * Several arguments may be optionally provided:
+	 * 
+	 * * `"call-signature"` checks return type of functions.
+	 * * `"arrow-call-signature"` checks return type of arrow functions.
+	 * * `"parameter"` checks type specifier of function parameters for non-arrow functions.
+	 * * `"arrow-parameter"` checks type specifier of function parameters for arrow functions.
+	 * * `"property-declaration"` checks return types of interface properties.
+	 * * `"variable-declaration"` checks non-binding variable declarations.
+	 * * `"variable-declaration-ignore-function"` ignore variable declarations for non-arrow and arrow functions.
+	 * * `"member-variable-declaration"` checks member variable declarations.
+	 * * `"object-destructuring"` checks object destructuring declarations.
+	 * * `"array-destructuring"` checks array destructuring declarations.
+	 *
+	 * @example
+	 * "typedef": [true,"call-signature","parameter","member-variable-declaration"]
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'typedef'?: ("call-signature" | "arrow-call-signature" | "parameter" | "arrow-parameter" | "property-declaration" | "variable-declaration" | "variable-declaration-ignore-function" | "member-variable-declaration" | "object-destructuring" | "array-destructuring")[],
+	/**
+	 * Requires or disallows whitespace for type definitions.
+	 *
+	 * Determines if a space is required or not before the colon in a type specifier.
+	 *
+	 * @options
+	 * Two arguments which are both objects.
+	 * The first argument specifies how much space should be to the _left_ of a typedef colon.
+	 * The second argument specifies how much space should be to the _right_ of a typedef colon.
+	 * Each key should have a value of `"onespace"`, `"space"` or `"nospace"`.
+	 * Possible keys are:
+	 * 
+	 * * `"call-signature"` checks return type of functions.
+	 * * `"index-signature"` checks index type specifier of indexers.
+	 * * `"parameter"` checks function parameters.
+	 * * `"property-declaration"` checks object property declarations.
+	 * * `"variable-declaration"` checks variable declaration.
+	 *
+	 * @example
+	 * "typedef-whitespace": [true,{"call-signature":"nospace","index-signature":"nospace","parameter":"nospace","property-declaration":"nospace","variable-declaration":"nospace"},{"call-signature":"onespace","index-signature":"onespace","parameter":"onespace","property-declaration":"onespace","variable-declaration":"onespace"}]
+	 *
+	 * @type formatting
+	 *
+	 * @typescriptOnly
+	 */
+	'typedef-whitespace'?: [{
+		'call-signature'?: "nospace" | "onespace" | "space",
+		'index-signature'?: "nospace" | "onespace" | "space",
+		parameter?: "nospace" | "onespace" | "space",
+		'property-declaration'?: "nospace" | "onespace" | "space",
+		'variable-declaration'?: "nospace" | "onespace" | "space",
+	}, {
+		'call-signature'?: "nospace" | "onespace" | "space",
+		'index-signature'?: "nospace" | "onespace" | "space",
+		parameter?: "nospace" | "onespace" | "space",
+		'property-declaration'?: "nospace" | "onespace" | "space",
+		'variable-declaration'?: "nospace" | "onespace" | "space",
+	}],
+	/**
+	 * Makes sure result of `typeof` is compared to correct string values
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "typeof-compare": true
+	 *
+	 * @type functionality
+	 */
+	'typeof-compare'?: any[],
+	/**
+	 * Warns for any two overloads that could be unified into one by using a union or an optional/rest parameter.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "unified-signatures": true
+	 *
+	 * @type typescript
+	 *
+	 * @typescriptOnly
+	 */
+	'unified-signatures'?: any[],
+	/**
+	 * Prevents unnecessary and/or misleading scope bindings on functions.
+	 *
+	 * @rationale
+	 * `function` expressions that are immediately bound to `this` are equivalent to `() =>` arrow lambdas.
+	 * Additionally, there's no use in binding a scope to an arrow lambda, as it already has one.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "unnecessary-bind": true
+	 *
+	 * @type style
+	 */
+	'unnecessary-bind'?: any[],
+	/**
+	 * Prevents blank constructors, as they are redundant.
+	 *
+	 * @rationale
+	 * JavaScript implicitly adds a blank constructor when there isn't one.
+	 * It's not necessary to manually add one in.
+	 *
+	 * @options
+	 * An optional object with the property 'check-super-calls'.
+	 * This is to check for unnecessary constructor parameters for super call
+	 *
+	 * @example
+	 * "unnecessary-constructor": true
+	 * "unnecessary-constructor": [true,{"check-super-calls":true}]
+	 *
+	 * @type functionality
+	 */
+	'unnecessary-constructor'?: {
+		'check-super-calls'?: boolean,
+	},
+	/**
+	 * Disallows `else` blocks following `if` blocks ending with a `break`, `continue`, `return`, or `throw` statement.
+	 *
+	 * @rationale
+	 * When an `if` block is guaranteed to exit control flow when entered,
+	 * it is unnecessary to add an `else` statement.
+	 * The contents that would be in the `else` block can be placed after the end of the `if` block.
+	 *
+	 * @options
+	 * You can optionally specify the option `"allow-else-if"` to allow "else if" statements.
+	 *
+	 * @example
+	 * "unnecessary-else": true
+	 * "unnecessary-else": [true,{"allow-else-if":true}]
+	 *
+	 * @type style
+	 */
+	'unnecessary-else'?: {
+		'allow-else-if'?: boolean,
+	},
+	/**
+	 * Warns if an explicitly specified type argument is the default for that type parameter.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * true
+	 *
+	 * @type functionality
+	 *
+	 * @typescriptOnly
+	 */
+	'use-default-type-parameter'?: any[],
+	/**
+	 * Enforces use of the `isNaN()` function to check for NaN references instead of a comparison to the `NaN` constant.
+	 *
+	 * @rationale
+	 * Since `NaN !== NaN`, comparisons with regular operators will produce unexpected results.
+	 * So, instead of `if (myVar === NaN)`, do `if (isNaN(myVar))`.
+	 *
+	 * @options
+	 * Not configurable.
+	 *
+	 * @example
+	 * "use-isnan": true
+	 *
+	 * @type functionality
+	 */
+	'use-isnan'?: any[],
+	/**
+	 * Checks variable names for various errors.
+	 *
+	 * @options
+	 * Several arguments may be optionally provided:
+	 * 
+	 * * `"check-format"` enbables enforcement of a certain naming format. By default, the rule only allows only lowerCamelCased or UPPER_CASED variable names.
+	 *   * These additional options make the check stricter:
+	 *     * `"require-const-for-all-caps"`: enforces that all variables with UPPER_CASED names should be `const`.
+	 *   * These additional options make the check more permissive:
+	 *     * `"allow-leading-underscore"` allows underscores at the beginning (only has an effect if "check-format" specified)
+	 *     * `"allow-pascal-case"` allows PascalCase in addition to lowerCamelCase.
+	 *     * `"allow-snake-case"` allows snake_case in addition to lowerCamelCase.
+	 *     * `"allow-trailing-underscore"` allows underscores at the end. (only has an effect if "check-format" specified)
+	 * * `"ban-keywords"`: disallows the use of certain TypeScript keywords as variable or parameter names.
+	 *   * These are: `any`, `Number`, `number`, `String`, `string`, `Boolean`, `boolean`, `Undefined`, `undefined`
+	 *
+	 * @example
+	 * "variable-name": {"options":["ban-keywords","check-format","allow-leading-underscore","allow-pascal-case"]}
+	 *
+	 * @type style
+	 */
+	'variable-name'?: ("check-format" | "allow-leading-underscore" | "allow-pascal-case" | "allow-snake-case" | "allow-trailing-underscore" | "require-const-for-all-caps" | "ban-keywords")[],
+	/**
+	 * Enforces whitespace style conventions.
+	 *
+	 * @rationale
+	 * Helps maintain a readable, consistent style in your codebase.
+	 *
+	 * @options
+	 * Several arguments may be optionally provided:
+	 * 
+	 * * `"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-module"` checks for whitespace in import & export statements.
+	 * * `"check-separator"` checks for whitespace after separator tokens (`,`/`;`).
+	 * * `"check-rest-spread"` checks that there is no whitespace after rest/spread operator (`...`).
+	 * * `"check-type"` checks for whitespace before a variable type specification.
+	 * * `"check-typecast"` checks for whitespace between a typecast and its target.
+	 * * `"check-type-operator"` checks for whitespace between type operators `|` and `&`.
+	 * * `"check-preblock"` checks for whitespace before the opening brace of a block.
+	 * * `"check-postbrace"` checks for whitespace after an opening brace.
+	 *
+	 * @example
+	 * "whitespace": [true,"check-branch","check-operator","check-typecast"]
+	 *
+	 * @type formatting
+	 */
+	'whitespace'?: ("check-branch" | "check-decl" | "check-operator" | "check-module" | "check-separator" | "check-rest-spread" | "check-type" | "check-typecast" | "check-type-operator" | "check-preblock" | "check-postbrace")[],
+}
+