Format all instances of Node.js per trademark guidelines

nwhitmont · nwhitmont · commit 69fb8b07e5fa · 2017-09-13T18:06:48.000-07:00
diff --git a/SUMMARY.md b/SUMMARY.md
@@ -34,7 +34,7 @@
     * [globals.d.ts](docs/project/globals.md)
   * [Namespaces](docs/project/namespaces.md)
   * [Dynamic Import Expressions](docs/project/dynamic-import-expressions.md)
-* [NodeJS QuickStart](docs/quick/nodejs.md)
+* [Node.js QuickStart](docs/quick/nodejs.md)
 * [Browser QuickStart](docs/quick/browser.md)
 * [TypeScript's Type System](docs/types/type-system.md)
   * [JS Migration Guide](docs/types/migrating.md)
diff --git a/docs/classes-emit.md b/docs/classes-emit.md
@@ -65,7 +65,7 @@ After having tutored many people about this I find the following explanation to
 1. effect of `new` on `this` inside the called function
 1. effect of `new` on `prototype` and `__proto__`
 
-All objects in JavaScript contain a `__proto__` member. This member is often not accessible in older browsers (sometimes documentation refers to this magical property as `[[prototype]]`). It has one objective: If a property is not found on an object during lookup (e.g. `obj.property`) then it is looked up at `obj.__proto__.property`. If it is still not found then `obj.__proto__.__proto__.property` till either: *it is found* or *the latest `.__proto__` itself is null*. This explains why JavaScript is said to support *prototypal inheritance* out of the box. This is shown in the following example, which you can run in the chrome console or nodejs:
+All objects in JavaScript contain a `__proto__` member. This member is often not accessible in older browsers (sometimes documentation refers to this magical property as `[[prototype]]`). It has one objective: If a property is not found on an object during lookup (e.g. `obj.property`) then it is looked up at `obj.__proto__.property`. If it is still not found then `obj.__proto__.__proto__.property` till either: *it is found* or *the latest `.__proto__` itself is null*. This explains why JavaScript is said to support *prototypal inheritance* out of the box. This is shown in the following example, which you can run in the chrome console or Node.js:
 
 ```ts
 var foo = {}
diff --git a/docs/future-javascript.md b/docs/future-javascript.md
@@ -1,4 +1,4 @@
 # Future JavaScript: Now
-One of the main selling points of TypeScript is that it allows you to use a bunch of features from ES6 and beyond in current (ES3 and ES5 level) JavaScript engines (like current browsers and NodeJS). Here we deep dive into why these features are useful followed by how these features are implemented in TypeScript.
+One of the main selling points of TypeScript is that it allows you to use a bunch of features from ES6 and beyond in current (ES3 and ES5 level) JavaScript engines (like current browsers and Node.js). Here we deep dive into why these features are useful followed by how these features are implemented in TypeScript.
 
 Note: Not all of these features are slated for immediate addition to JavaScript but provide great utility to your code organization and maintenance. Also note that you are free to ignore any of the constructs that don't make sense for your project, although you will end up using most of them eventually ;)
diff --git a/docs/javascript/closure.md b/docs/javascript/closure.md
@@ -54,7 +54,7 @@ counter.increment();
 console.log(counter.getVal()); // 2
 ```
 
-At a high level it is also what makes something like nodejs possible (don't worry if it doesn't click in your brain right now. It will eventually 🌹):
+At a high level it is also what makes something like Node.js possible (don't worry if it doesn't click in your brain right now. It will eventually 🌹):
 
 ```ts
 // Pseudo code to explain the concept
diff --git a/docs/project/external-modules.md b/docs/project/external-modules.md
@@ -35,7 +35,7 @@ import foo = require('foo');
 
 will generate *different* JavaScript based on the compiler *module* option (`--module commonjs` or `--module amd` or `--module umd` or `--module system`).
 
-Personal recommendation: use `--module commonjs` and then your code will work as it is for NodeJS and for frontend you can use something like `webpack`.
+Personal recommendation: use `--module commonjs` and then your code will work as it is for Node.js and for frontend you can use something like `webpack`.
 
 ### Import type only
 The following statement:
diff --git a/docs/project/module-resolution.md b/docs/project/module-resolution.md
@@ -48,7 +48,7 @@ declare module "foo" {
 This makes the module `"foo"`, *importable*.
 
 ## Node Modules
-The node module resolution is actually pretty much the same one used by NodeJS / NPM ([official nodejs docs](https://nodejs.org/api/modules.html#modules_all_together)). Here is a simple mental model I have:
+The node module resolution is actually pretty much the same one used by Node.js / NPM ([official nodejs docs](https://nodejs.org/api/modules.html#modules_all_together)). Here is a simple mental model I have:
 
 * module `foo/bar` will resolve to some file : `node_modules/foo` (the module) + `foo/bar`
 
diff --git a/docs/quick/browser.md b/docs/quick/browser.md
@@ -3,7 +3,7 @@ If you are using TypeScript to create a web application here are my recommendati
 
 ## General Machine Setup
 
-* Install [NodeJS](https://nodejs.org/en/download/)
+* Install [Node.js](https://nodejs.org/en/download/)
 
 ## Project Setup
 * Create a project dir:
diff --git a/docs/quick/nodejs.md b/docs/quick/nodejs.md
@@ -1,9 +1,9 @@
-# TypeScript with NodeJS
-TypeScript has had *first class* support for NodeJS since inception. Here's how to setup a quick NodeJS project:
+# TypeScript with Node.js
+TypeScript has had *first class* support for Node.js since inception. Here's how to setup a quick Node.js project:
 
-> Note: many of these steps are actually just common practice nodejs setup steps
+> Note: many of these steps are actually just common practice Node.js setup steps
 
-1. Setup a nodejs project `package.json`. Quick one : `npm init -y`
+1. Setup a Node.js project `package.json`. Quick one : `npm init -y`
 1. Add TypeScript (`npm install typescript --save-dev`)
 1. Add `node.d.ts` (`npm install @types/node --save-dev`)
 1. Init a `tsconfig.json` for TypeScript options (`node ./node_modules/typescript/lib/tsc --init`)
@@ -28,7 +28,7 @@ So you can now run `npm start` and as you edit `index.ts`:
 
 * nodemon reruns its command (ts-node)
 * ts-node transpiles automatically picking up tsconfig.json and the installed typescript version,
-* ts-node runs the output javascript through node.
+* ts-node runs the output javascript through Node.js.
 
 ## Creating TypeScript node modules
 
@@ -62,7 +62,7 @@ package
   * have `include: ["./src/**/*]"` < This includes all the files from the `src` dir.
 
 * In your `package.json` have
-  * `"main": "lib/index"` < This tells NodeJS to load `lib/index.js`
+  * `"main": "lib/index"` < This tells Node.js to load `lib/index.js`
   * `"types": "lib/index"` < This tells TypeScript to load `lib/index.d.ts`
 
 
diff --git a/docs/styleguide/styleguide.md b/docs/styleguide/styleguide.md
@@ -182,7 +182,7 @@ return undefined;
 
 * Use `null` where its a part of the API or conventional
 
-> Reason: It is conventional in NodeJS e.g. `error` is `null` for NodeBack style callbacks.
+> Reason: It is conventional in Node.js e.g. `error` is `null` for NodeBack style callbacks.
 
 **Bad**
 ```ts
diff --git a/docs/tips/typed-event.md b/docs/tips/typed-event.md
@@ -1,6 +1,6 @@
 ## Typesafe Event Emitter
 
-Conventionally in NodeJS and traditional JavaScript you have a single event emitter. This event emitter internally tracks listener for different event types e.g. 
+Conventionally in Node.js and traditional JavaScript you have a single event emitter. This event emitter internally tracks listener for different event types e.g. 
 
 ```js
 const emitter = new EventEmitter();
diff --git a/docs/types/ambient/d.ts.md b/docs/types/ambient/d.ts.md
@@ -1,5 +1,5 @@
 ### Declaration file
-You can tell TypeScript that you are trying to describe code that exists elsewhere (e.g. written in JavaScript/CoffeeScript/The runtime environment like the browser or nodejs) using the `declare` keyword. As a quick example:
+You can tell TypeScript that you are trying to describe code that exists elsewhere (e.g. written in JavaScript/CoffeeScript/The runtime environment like the browser or Node.js) using the `declare` keyword. As a quick example:
 
 ```ts
 foo = 123; // Error: `foo` is not defined
diff --git a/docs/types/exceptions.md b/docs/types/exceptions.md
@@ -62,7 +62,7 @@ catch(e) {
 Raw strings result in a very painful debugging experience and complicate error analysis from logs.
 
 ## You don't have to `throw` an error
-It is okay to pass an `Error` object around. This is conventional in NodeJS callback style code which take callbacks with the first argument as an error object.
+It is okay to pass an `Error` object around. This is conventional in Node.js callback style code which take callbacks with the first argument as an error object.
 
 ```js
 function myFunction (callback: (e?: Error)) {
diff --git a/docs/types/generics.md b/docs/types/generics.md
@@ -158,7 +158,7 @@ const Form = ()=> <StringSelect items={['a', 'b']} />;
 
 ## Useless Generic
 
-I've seen people use generics just for the heck of it. The question to ask is *what constraint are you trying to describe*. If you can't answer it easily you probably have a useless generic. E.g. people have attempted to type the nodejs `require` function as:
+I've seen people use generics just for the heck of it. The question to ask is *what constraint are you trying to describe*. If you can't answer it easily you probably have a useless generic. E.g. people have attempted to type the Node.js `require` function as:
 
 ```ts
 declare function require<T>(name: string): T;
