docs: Add note about usage with ts-node (palantir#3164)

Also replace `grunt test` with `yarn compile:test && yarn tets:rules`

[no-log]

docs/develop/custom-rules/index.md

@@ -8,11 +8,11 @@ TSLint ships with a set of core rules that can be configured. However, users are
 
 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__: 
+__Important conventions__:
 
 - Rule identifiers are always kebab-cased.
 - Rule files are always camel-cased (`camelCasedRule.ts`).
-- Rule files *must* contain the suffix `Rule`. 
+- 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:
@@ -55,7 +55,7 @@ Finally, add a line to your [`tslint.json` config file][0] for each of your cust
 
 ---
 
-Now that you're written a rule to detect problems, let's modify it to *fix* them. 
+Now that you're written a rule to detect problems, let's modify it to *fix* them.
 
 Instantiate a `Fix` object and pass it in as an argument to `addFailure`. This snippet replaces the offending import statement with an empty string:
 
@@ -71,5 +71,12 @@ 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()`).
+- As of TSLint v5.7.0 you no longer need to compile your custom rules before using them. You need to tell node.js how to load `.ts` files for example by using `ts-node`:
+
+```sh
+ts-node node_modules/.bin/tslint <your options>
+# or
+node -r ts-node/register node_modules/.bin/tslint <your options>
+```
 
 [0]: {{site.baseurl | append: "/usage/tslint-json/"}}

docs/develop/testing-rules/index.md

@@ -9,7 +9,7 @@ Every TSLint rule has a corresponding directory inside `test/rules/` which conta
 Each test case contains:
 
 * A `tslint.json` file which specifies the configuration for TSLint to use
-* `.ts.lint` test files which contain TypeScript code and a special markup which indicate where lint failures should be found  
+* `.ts.lint` test files which contain TypeScript code and a special markup which indicate where lint failures should be found
 
 The test system lints the `.ts.lint` files with the settings specified in `tslint.json` and makes sure that failures generated by the TSLint match the failures marked in the `.ts.lint` files.
 
@@ -35,7 +35,7 @@ Now let's make the actual test file:
 
 `test/rules/no-animal-variable-names/default/test.ts.lint`:
 
-``` 
+```
 const octopus = 5;
       ~~~~~~~      [Variables named after animals are not allowed!]
 
@@ -56,7 +56,7 @@ as shown in the above example with the line `let giraffe: number, tiger: number;
 Notice how we also include lines of code that *shouldn't* generate lint failures.
 This is important to ensure that the rule isn't creating false-positives.
 
-We can now run `grunt test` to make sure that our rule produces the output we expect.
+We can now run `yarn compile:test && yarn test:rules` to make sure that our rule produces the output we expect.
 
 ##### Testing a New Rule Option #####
 
@@ -74,7 +74,7 @@ Let's look at one more example. Say we've added an `also-no-plants` option to ou
 
 `test/rules/no-animal-variable-names/also-no-plants/test.ts.lint`:
 
-``` 
+```
 const octopus = 5;
       ~~~~~~~     [no-animal]
 
@@ -95,11 +95,11 @@ Instead of writing out the full lint failure message after each occurance of it,
 (Shortcut names can only consist of letters, numbers, underscores, and hyphens.)
 Then, at the bottom of our test file, we specify what full message each shortcut should expand to.
 
-Again, we can run `grunt test` to make sure our rule is producing the output we expect. If it isn't we'll see the difference between the output from the rule and the output we marked.
+Again, we can run `yarn compile:test && yarn test:rules` to make sure our rule is producing the output we expect. If it isn't we'll see the difference between the output from the rule and the output we marked.
 
 You can also use placeholders to format messages. That's useful if the error message contains non-static parts, e.g. variable names. But let's stick to the above example for now.
 
-``` 
+```
 const octopus = 5;
       ~~~~~~~     [no-animal]
 
@@ -124,7 +124,7 @@ If you use formatting in another message shorthand (like we did for `[no-animal]
 
 Now let's pretend the rule changed its error message to include the variable name at the end. The following example shows how to substitute multiple placeholders.
 
-``` 
+```
 const octopus = 5;
       ~~~~~~~     [no-animal % ('octopus')]