update non-generated docs (palantir#1726)

README.md

@@ -79,9 +79,15 @@ The configuration file specifies which rules are enabled and their options. Thes
   "extends": "tslint:latest",
   "rules": {
     /*
-     * Any rules specified here will override those from the base config we are extending
+     * Any rules specified here will override those from the base config we are extending.
      */
-    "no-parameter-properties": true
+    "curly": true
+  },
+  "jsRules": {
+    /*
+     * Any rules specified here will override those from the base config we are extending.
+     */
+    "curly": true
   },
   "rulesDirectory": [
     /*
@@ -108,16 +114,17 @@ Options:
 
 ```
 -c, --config          configuration file
+-e, --exclude         exclude globs from path expansion
+--fix                 Fixes linting errors for select rules. This may overwrite linted files
 --force               return status code 0 even if there are lint errors
 -h, --help            display detailed help
 -i, --init            generate a tslint.json config file in the current working directory
 -o, --out             output file
+--project             tsconfig.json file
 -r, --rules-dir       rules directory
 -s, --formatters-dir  formatters directory
--e, --exclude         exclude globs from path expansion
--t, --format          output format (prose, json, verbose, pmd, msbuild, checkstyle)  [default: "prose"]
+-t, --format          output format (prose, json, stylish, verbose, pmd, msbuild, checkstyle, vso, fileslist)  [default: "prose"]
 --test                test that tslint produces the correct output for the specified directory
---project             path to tsconfig.json file
 --type-check          enable type checking when linting a project
 -v, --version         current version
 ```
@@ -145,6 +152,9 @@ tslint accepts the following command-line options:
     This option can be supplied multiple times if you need multiple
     globs to indicate which files to exclude.
 
+--fix:
+    Fixes linting errors for select rules. This may overwrite linted files.
+
 --force:
     Return status code 0 even if there are any lint errors.
     Useful while running as npm script.
@@ -301,15 +311,19 @@ If we don't have all the rules you're looking for, you can either write your own
 
 TSLint ships with a set of core rules that can be configured. However, users are also allowed to write their own rules, which allows them to enforce specific behavior not covered by the core of TSLint. TSLint's internal rules are itself written to be pluggable, so adding a new rule is as simple as creating a new rule file named by convention. New rules can be written in either TypeScript or JavaScript; if written in TypeScript, the code must be compiled to JavaScript before invoking TSLint.
 
-Rule names are always camel-cased and *must* contain the suffix `Rule`. Let us take the example of how to write a new rule to forbid all import statements (you know, *for science*). Let us name the rule file `noImportsRule.ts`. Rules can be referenced in `tslint.json` in their kebab-case forms, so `"no-imports": true` would turn on the rule.
+Let us take the example of how to write a new rule to forbid all import statements (you know, *for science*). Let us name the rule file `noImportsRule.ts`. Rules are referenced in `tslint.json` with their kebab-cased identifer, so `"no-imports": true` would configure the rule.
+
+__Important conventions__: 
+* Rule identifiers are always kebab-cased.
+* Rule files are always camel-cased (`camelCasedRule.ts`).
+* Rule files *must* contain the suffix `Rule`. 
+* The exported class must always be named `Rule` and extend from `Lint.Rules.AbstractRule`.
 
-Now, let us first write the rule in TypeScript. A few things to note:
-- We import `tslint/lib/lint` to get the whole `Lint` namespace instead of just the `Linter` class.
-- The exported class must always be named `Rule` and extend from `Lint.Rules.AbstractRule`.
+Now, let us first write the rule in TypeScript:
 
 ```typescript
 import * as ts from "typescript";
-import * as Lint from "tslint/lib/lint";
+import * as Lint from "tslint";
 
 export class Rule extends Lint.Rules.AbstractRule {
     public static FAILURE_STRING = "import statement forbidden";
@@ -336,11 +350,13 @@ Given a walker, TypeScript's parser visits the AST using the visitor pattern. So
 We still need to hook up this new rule to TSLint. First make sure to compile `noImportsRule.ts`:
 
 ```bash
-tsc -m commonjs --noImplicitAny noImportsRule.ts node_modules/tslint/lib/tslint.d.ts
+tsc --noImplicitAny noImportsRule.ts
 ```
 
 Then, if using the CLI, provide the directory that contains this rule as an option to `--rules-dir`. If using TSLint as a library or via `grunt-tslint`, the `options` hash must contain `"rulesDirectory": "..."`. If you run the linter, you'll see that we have now successfully banned all import statements via TSLint!
 
+Finally, enable each custom rule in your [`tslint.json` config file][0] config file.
+
 Final notes:
 
 - Core rules cannot be overwritten with a custom implementation.
@@ -396,3 +412,5 @@ Creating a new release
 4. Commit with message `Prepare release <version>`
 5. Run `npm publish`
 6. Create a git tag for the new release and push it ([see existing tags here](https://github.com/palantir/tslint/tags))
+
+[0]: {{site.baseurl | append: "/usage/tslint-json/"}}

docs/develop/contributing/index.md

@@ -4,17 +4,18 @@ title: Contributing
 permalink: /develop/contributing/
 ---
 
-To develop TSLint simply clone the repository, install dependencies and run grunt:
+To develop TSLint simply clone the repository and install dependencies:
 
 ```bash
-git clone [email protected]:palantir/tslint.git
+git clone [email protected]:palantir/tslint.git --config core.autocrlf=input --config core.eol=lf
 npm install
-grunt
+npm run compile
+npm run test
 ```
 
 #### `next` branch
 
 The [`next` branch of the TSLint repo](https://github.com/palantir/tslint/tree/next) tracks the latest TypeScript
 compiler as a `devDependency`. This allows you to develop the linter and its rules against the latest features of the
 language. Releases from this branch are published to npm with the `next` dist-tag, so you can get the latest dev
-version of TSLint via `npm install tslint@next`.
+version of TSLint via `npm install tslint@next`.

docs/develop/custom-rules/index.md

@@ -3,20 +3,21 @@ title: Custom Rules
 layout: page
 permalink: "/develop/custom-rules/"
 ---
-TSLint ships with a set of core rules that can be configured. However, users are also enabled to write their own rules, which allows them to enforce specific behavior not covered by the core of TSLint. TSLint's internal rules are itself written to be pluggable, so adding a new rule is as simple as creating a new rule file named by convention. New rules can be written in either TypeScript or Javascript; if written in TypeScript, the code must be compiled to Javascript before registering them with TSLint.
-
-__Important conventions__: Rule identifiers are always kebab-cased. Their implementation files are always `camelCasedRule.ts` and *must* contain the suffix `Rule`. 
+TSLint ships with a set of core rules that can be configured. However, users are also allowed to write their own rules, which allows them to enforce specific behavior not covered by the core of TSLint. TSLint's internal rules are itself written to be pluggable, so adding a new rule is as simple as creating a new rule file named by convention. New rules can be written in either TypeScript or JavaScript; if written in TypeScript, the code must be compiled to JavaScript before invoking TSLint.
 
 Let us take the example of how to write a new rule to forbid all import statements (you know, *for science*). Let us name the rule file `noImportsRule.ts`. Rules are referenced in `tslint.json` with their kebab-cased identifer, so `"no-imports": true` would configure the rule.
 
-Now, let us first write the rule in TypeScript. A few things to note:
+__Important conventions__: 
+* Rule identifiers are always kebab-cased.
+* Rule files are always camel-cased (`camelCasedRule.ts`).
+* Rule files *must* contain the suffix `Rule`. 
+* The exported class must always be named `Rule` and extend from `Lint.Rules.AbstractRule`.
 
-- We import `tslint/lib/lint` to get the whole `Lint` namespace instead of just the `Linter` class.
-- The exported class must always be named `Rule` and extend from `Lint.Rules.AbstractRule`.
+Now, let us first write the rule in TypeScript:
 
-```ts
+```typescript
 import * as ts from "typescript";
-import * as Lint from "tslint/lib/lint";
+import * as Lint from "tslint";
 
 export class Rule extends Lint.Rules.AbstractRule {
     public static FAILURE_STRING = "import statement forbidden";
@@ -55,4 +56,4 @@ Final notes:
 - Core rules cannot be overwritten with a custom implementation.
 - Custom rules can also take in options just like core rules (retrieved via `this.getOptions()`).
 
-[0]: {{site.baseurl | append: "/usage/tslint-json/"}}
+[0]: {{site.baseurl | append: "/usage/tslint-json/"}}

docs/develop/docs/index.md

@@ -9,10 +9,10 @@ It is maintained in the [`/docs` directory][2] of TSLint.
 To contribute to the docs, whether it be better styling, functionality, or content, just create a PR as you would for any code contribution.
 
 #### Updating Rule Documentation ####
-The [documentation for rules][3] is automatically generated from the metadata supplied by each rule in its corresponding `.tsx` file.
+The [documentation for rules][3] is automatically generated from the metadata supplied by each rule in its corresponding `.ts` file.
 If you'd like to help improve documentation for them, simply file a PR improving a rule's metadata and a project collaborator will take care of regenerating the docs site once your PR is merged.
 
-Running the `grunt docs` command will regenerate the rules docs based off of the metadata provided in the code. This is normally done each release so that the public docs site is up to date with the latest release.
+Running the `npm run docs` command will regenerate the rules docs based off of the metadata provided in the code. This is normally done each release so that the public docs site is up to date with the latest release.
 
 #### Creating New Pages ####
 To create a new page, follow the pattern of existing pages. You'll also need to add appropriate metadata in the `_data/*_sidebar.json` data file if you want it to show up in a sidebar.

docs/usage/cli/index.md

@@ -30,15 +30,18 @@ Options:
 
 ```
 -c, --config          configuration file
+-e, --exclude         exclude globs from path expansion
+--fix                 Fixes linting errors for select rules. This may overwrite linted files
 --force               return status code 0 even if there are lint errors
 -h, --help            display detailed help
 -i, --init            generate a tslint.json config file in the current working directory
 -o, --out             output file
+--project             tsconfig.json file
 -r, --rules-dir       rules directory
 -s, --formatters-dir  formatters directory
--e, --exclude         exclude globs from path expansion
--t, --format          output format (prose, json, verbose, pmd, msbuild, checkstyle, vso)    [default: "prose"]
+-t, --format          output format (prose, json, stylish, verbose, pmd, msbuild, checkstyle, vso, fileslist)  [default: "prose"]
 --test                test that tslint produces the correct output for the specified directory
+--type-check          enable type checking when linting a project
 -v, --version         current version
 ```
 
@@ -54,7 +57,7 @@ tslint accepts the following command-line options:
     to the rules. If no option is specified, the config file named
     tslint.json is used, so long as it exists in the path.
     The format of the file is { rules: { /* rules list */ } },
-    where /* rules list */ is a key: value comma-seperated list of
+    where /* rules list */ is a key: value comma-separated list of
     rulename: rule-options pairs. Rule-options can be either a
     boolean true/false value denoting whether the rule is used or not,
     or a list [boolean, ...] where the boolean provides the same role
@@ -68,6 +71,9 @@ tslint accepts the following command-line options:
     This option can be supplied multiple times if you need multiple
     globs to indicate which files to exclude.
 
+--fix:
+    Fixes linting errors for select rules. This may overwrite linted files.
+
 --force:
     Return status code 0 even if there are any lint errors.
     Useful while running as npm script.
@@ -109,6 +115,14 @@ tslint accepts the following command-line options:
     specified directory as the configuration file for the tests. See the
     full tslint documentation for more details on how this can be used to test custom rules.
 
+--project:
+    The location of a tsconfig.json file that will be used to determine which
+    files will be linted.
+
+--type-check
+    Enables the type checker when running linting rules. --project must be
+    specified in order to enable type checking.
+
 -v, --version:
     The current version of tslint.
 

docs/usage/tslint-json/index.md

@@ -20,7 +20,8 @@ A path(s) to a directory of [custom rules][2]. This will always be treated as a
 * `rules?: any`: Pairs of keys and values where each key is a rule name and each value is the configuration for that rule.
 If a rule takes no options, you can simply set its value to a boolean, either `true` or `false`, to enable or disable it.
 If a rule takes options, you set its value to an array where the first value is a boolean indicating if the rule is enabled and the next values are options handled by the rule.
-Not all possible rules are listed here, be sure to [check out the full list][3].
+Not all possible rules are listed here, be sure to [check out the full list][3]. These rules are applied to `.ts` and `.tsx` files.
+* `jsRules?: any`: Same format as `rules`. These rules are applied to `.js` and `.jsx` files. 
 
 `tslint.json` configuration files may have JavaScript-style `// single-line` and `/* multi-line */` comments in them (even though this is technically invalid JSON). If this confuses your syntax highlighter, you may want to switch it to JavaScript format.
 
@@ -57,6 +58,24 @@ An example `tslint.json` file might look like this:
             "check-separator",
             "check-type"
         ]
+    },
+    "jsRules": {
+        "indent": [true, "spaces"],
+        "no-duplicate-variable": true,
+        "no-eval": true,
+        "no-trailing-whitespace": true,
+        "one-line": [true, "check-open-brace", "check-whitespace"],
+        "quotemark": [true, "double"],
+        "semicolon": false,
+        "triple-equals": [true, "allow-null-check"],
+        "variable-name": [true, "ban-keywords"],
+        "whitespace": [true,
+            "check-branch",
+            "check-decl",
+            "check-operator",
+            "check-separator",
+            "check-type"
+        ]
     }
 }
 ```

package.json

@@ -5,8 +5,8 @@
   "bin": {
     "tslint": "./bin/tslint"
   },
-  "main": "./lib/tslint/index.js",
-  "typings": "./lib/tslint/index.d.ts",
+  "main": "./lib/index.js",
+  "typings": "./lib/index.d.ts",
   "repository": {
     "type": "git",
     "url": "https://github.com/palantir/tslint.git"
@@ -69,8 +69,5 @@
   "peerDependencies": {
     "typescript": ">=2.0.0"
   },
-  "license": "Apache-2.0",
-  "typescript": {
-    "definition": "lib/tslint.d.ts"
-  }
+  "license": "Apache-2.0"
 }

src/tslint-cli.ts

@@ -192,7 +192,7 @@ tslint accepts the following commandline options:
         formatters are prose (human readable), json (machine readable)
         and verbose. prose is the default if this option is not used.
         Other built-in options include pmd, msbuild, checkstyle, and vso.
-        Additonal formatters can be added and used if the --formatters-dir
+        Additional formatters can be added and used if the --formatters-dir
         option is set.
 
     --test: