fix lint.js and some lints

weswigham · weswigham · commit 4d8a7cde26a3 · 2015-10-16T16:21:01.000-07:00
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,8 +1,10 @@
 ## Contributing
+
 TypeScript-Handbook is accepting contributions. If you've submitted a PR for an existing issue, please post a comment in the issue to avoid duplication of effort.
 
 
 ## Housekeeping
+
 Your pull request should:
 
 * Include a description of what your change intends to do.
diff --git a/lint.js b/lint.js
@@ -7,10 +7,10 @@ var options = {
     MD001: false, // Header levels should only increment by one level at a time
     MD002: false, // First header should be a h1 header
     MD003: false, // Header style
-    MD004: "asterisk", // Unordered list style
+    MD004: {style: "asterisk"}, // Unordered list style
     MD005: true, // Inconsistent indentation for list items at the same level
     MD006: true, // Consider starting bulleted lists at the beginning of the line
-    MD007: 4, // Unordered list indentation
+    MD007: {indent: 4}, // Unordered list indentation
     MD009: true, // Trailing spaces
     MD010: true, // Hard tabs
     MD011: true, // Reversed link syntax
@@ -25,10 +25,10 @@ var options = {
     MD023: true, // Headers must start at the beginning of the line
     MD024: false, // Multiple headers with the same content
     MD025: false, // Multiple top level headers in the same document
-    MD026: ".,;:!?", // Trailing punctuation in header
+    MD026: {punctuation: ".,;:!?"}, // Trailing punctuation in header
     MD027: true, // Multiple spaces after blockquote symbol
     MD028: false, // Blank line inside blockquote
-    MD029: "ordered", // Ordered list item prefix
+    MD029: {style: "ordered"}, // Ordered list item prefix
     MD030: true, // Spaces after list markers
     MD031: true, // Fenced code blocks should be surrounded by blank lines
     MD032: true, // Lists should be surrounded by blank lines
diff --git a/pages/Basic Types.md b/pages/Basic Types.md
@@ -119,15 +119,15 @@ notSure = false; // okay, definitely a boolean
 ```
 
 The `any` type is a powerful way to work with existing JavaScript, allowing you to gradually opt-in and opt-out of type-checking during compilation.
-You might expect `Object` to play a similar role, as it does in other languages. 
+You might expect `Object` to play a similar role, as it does in other languages.
 But variables of type `Object` only allow you to assign any value to them -- you can't call arbitrary methods on them, even ones that actually exist:
 
 ```TypeScript
 var notSure: any = 4;
 notSure.ifItExists(); // okay, ifItExists might exist at runtime
 notSure.toFixed(); // okay, toFixed exists (but the compiler doesn't check)
 var prettySure: Object = 4;
-prettySure.toFixed(); // Error: Property 'toFixed' doesn't exist on type 'Object'. 
+prettySure.toFixed(); // Error: Property 'toFixed' doesn't exist on type 'Object'.
 ```
 
 The `any` type is also handy if you know some part of the type, but perhaps not all of it.
diff --git a/pages/Classes.md b/pages/Classes.md
@@ -23,7 +23,7 @@ var greeter = new Greeter("world");
 ```
 
 The syntax should look familiar if you've used C# or Java before.
-We declare a new class `Greeter`. This class has three members: a property called `greeting`, a constructor, and a method `greet`. 
+We declare a new class `Greeter`. This class has three members: a property called `greeting`, a constructor, and a method `greet`.
 
 You'll notice that in the class when we refer to one of the members of the class we prepend `this.`.
 This denotes that it's a member access.
@@ -119,7 +119,7 @@ new Animal("Cat").name; // Error: 'name' is private;
 ```
 
 TypeScript is a structural type system.
-When we compare two different types, regardless of where they came from, if the types of all members are compatible, then we say the types themselves are compatible. 
+When we compare two different types, regardless of where they came from, if the types of all members are compatible, then we say the types themselves are compatible.
 
 However, when comparing types that have `private` and `protected` members, we treat these types differently.
 For two types to be considered compatible, if one of them has a `private` member, then the other must have a `private` member that originated in the same declaration.
@@ -139,7 +139,7 @@ class Rhino extends Animal {
 
 class Employee {
     private name: string;
-    constructor(theName: string) { this.name = theName; }	
+    constructor(theName: string) { this.name = theName; }
 }
 
 var animal = new Animal("Goat");
@@ -228,7 +228,7 @@ if (employee.fullName) {
 }
 ```
 
-While allowing people to randomly set fullName directly is pretty handy, this might get us in trouble if we people can change names on a whim. 
+While allowing people to randomly set fullName directly is pretty handy, this might get us in trouble if we people can change names on a whim.
 
 In this version, we check to make sure the user has a secret passcode available before we allow them to modify the employee.
 We do this by replacing the direct access to fullName with a `set` that will check the passcode.
@@ -243,7 +243,7 @@ class Employee {
     get fullName(): string {
         return this._fullName;
     }
-	
+
     set fullName(newName: string) {
         if (passcode && passcode == "secret passcode") {
             this._fullName = newName;
