Small Grammar and Wording Changes

chapters/Basics.md

@@ -185,7 +185,7 @@ npm install -g typescript
 > This installs the TypeScript Compiler `tsc` globally.
 > You can use `npx` or similar tools if you'd prefer to run `tsc` from a local `node_modules` package instead.
 
-Now let's move to an empty folder and try writing our first TypeScript program: `hello.ts`:
+Now create an empty directory named ts-example and create a new file called: `hello.ts` and input the following code:
 
 ```ts
 // Greets the world.
@@ -208,7 +208,7 @@ Well, there were no type errors, so we didn't get any output in our console sinc
 But check again - we got some *file* output instead.
 If we look in our current directory, we'll see a `hello.js` file next to `hello.ts`.
 That's the output from our `hello.ts` file after `tsc` *compiles* or *transforms* it into a JavaScript file.
-And if we check the contents, we'll see what TypeScript spits out after it processes a `.ts` file:
+And if we check the contents of the .js file, we'll see what TypeScript spits out after it processes a `.ts` file:
 
 ```js
 // Greets the world.
@@ -217,7 +217,10 @@ console.log("Hello world!");
 
 In this case, there was very little for TypeScript to transform, so it looks identical to what we wrote.
 The compiler tries to emit clean readable code that looks like something a person would write.
-While that's not always so easy, TypeScript indents consistently, is mindful of when our code spans across different lines of code, and tries to keep comments around.
+While that's not always so easy, TypeScript:
+* Indents consistently 
+* Is mindful of when our code spans across different lines of code
+* And tries to keep comments around
 
 What about if we *did* introduce a type-checking error?
 Let's rewrite `hello.ts`:
@@ -246,7 +249,7 @@ Thanks TypeScript!
 
 One thing you might not have noticed from the last example was that our `hello.js` file changed again.
 If we open that file up then we'll see that the contents still basically look the same as our input file.
-That might be a bit surprising given the fact that `tsc` reported an error about our code, but this based on one of TypeScript's core values: much of the time, *you* will know better than TypeScript.
+That might be a bit surprising given the fact that `tsc` reported an error about our code, but this is based on one of TypeScript's core values: much of the time, *you* will know better than TypeScript.
 
 To reiterate from earlier, type-checking code limits the sorts of programs you can run, and so there's a tradeoff on what sorts of things a type-checker finds acceptable.
 Most of the time that's okay, but there are scenarios where those checks get in the way.
@@ -321,7 +324,7 @@ That's a feature, and it's best not to add annotations when the type system woul
 
 ## Erased Types
 
-Let's take a look at what happens when we compile with `tsc`:
+Let's take a look at the differences in the JavaScript code created from `tsc`:
 
 ```js
 function greet(person, date) {

chapters/More on Functions.md

@@ -525,15 +525,15 @@ function noop() {
 
 In JavaScript, a function that doesn't return any value will implicitly return the value `undefined`.
 However, `void` and `undefined` are not the same thing in TypeScript.
-See the reference page [[Why void is a special type]] for a longer discussion about this.
+See the reference page [[Why Void Is A Special Type]] for a longer discussion about this.
 
 > `void` is not the same as `undefined`.
 
 ### `object`
 
 The special type `object` refers to any value that isn't a primitive (`string`, `number`, `boolean`, `symbol`, `null`, or `undefined`).
 This is different from the *empty object type* `{ }`, and also different from the global type `Object`.
-You can read the reference page about [[The global types]] for information on what `Object` is for - long story short, don't ever use `Object`.
+You can read the reference page about [[The Global Types]] for information on what `Object` is for - long story short, don't ever use `Object`.
 
 > `object` is not `Object`. **Always** use `object`!
 

chapters/Narrowing.md

@@ -187,7 +187,7 @@ TypeScript doesn't hurt us here at all, but this is behavior worth noting if you
 TypeScript can often help you catch bugs early on, but if you choose to do *nothing* with a value, there's only so much that it can do without being overly prescriptive.
 If you want, you can make sure you handle situations like these with a linter.
 
-One last word on narrowing by truthiness is that Boolean negations with `!` filter out from negated branches.
+One last word on narrowing by truthiness is that Boolean negations with `!`, filter out from negated branches.
 
 ```ts
 function multiplyAll(values: number[] | undefined, factor: number): number[] | undefined {

chapters/Type Declarations.md

@@ -85,7 +85,7 @@ TypeScript automatically finds type definitions under `node_modules/@types`, so
 
 ### Your Own Definitions
 
-In the uncommon event that a library didn't bundle its own types and didn't have a definition on DefinitelyTyped, you can write a declaration file yourself.
+In the uncommon event that a library didn't bundle its own types and does not have a definition in the DefinitelyTyped repo, you can write a declaration file yourself.
 See the appendix [[Writing Declaration Files]] for a guide.
 
 If you want to silence warnings about a particular module without writing a declaration file, you can also quick declare the module as type `any` by putting an empty declaration for it in a `.d.ts` file in your project.

chapters/Types from Transformation.md

@@ -171,9 +171,8 @@ For example, we could have inferred the element type in `Flatten` instead of fet
 type Flatten<T> = T extends Array<infer U> ? U : T;
 ```
 
-Here, we used the `infer` keyword declaratively introduced a new generic type variable named `U` instead of specifying how to retrieve the element type of `T`.
-Within the true branch
-This frees us from having to think about how to dig through and probing apart the structure of the types we're interested.
+Here, using the `infer` keyword declaratively introduced a new generic type variable named `U` instead of specifying how to retrieve the element type of `T`.
+This frees us from having to think about how to dig through and probe apart the structure of the types we're interested.
 
 We can write some useful helper type aliases using the `infer` keyword.
 For example, for simple cases, we can extract the return type out from function types: