Docs: Replace all node references to Node.js which is the official name

docs/rules/README.md

@@ -140,8 +140,8 @@ These rules are specific to JavaScript running on Node.js or using CommonJS in t
 * [no-new-require](no-new-require.md) - disallow use of `new` operator with the `require` function
 * [no-path-concat](no-path-concat.md) - disallow string concatenation with `__dirname` and `__filename`
 * [no-process-exit](no-process-exit.md) - disallow `process.exit()`
-* [no-restricted-imports](no-restricted-imports.md) - restrict usage of specified node imports
-* [no-restricted-modules](no-restricted-modules.md) - restrict usage of specified node modules
+* [no-restricted-imports](no-restricted-imports.md) - restrict usage of specified Node.js imports
+* [no-restricted-modules](no-restricted-modules.md) - restrict usage of specified Node.js modules
 * [no-sync](no-sync.md) - disallow use of synchronous methods
 
 ## Stylistic Issues

docs/rules/callback-return.md

@@ -14,7 +14,7 @@ function doSomething(err, callback) {
 
 To prevent calling the callback multiple times it is important to `return` anytime the callback is triggered outside
  of the main function body. Neglecting this technique often leads to issues where you do something more than once.
- For example, in the case of an HTTP request, you may try to send HTTP headers more than once leading node.js to `throw`
+ For example, in the case of an HTTP request, you may try to send HTTP headers more than once leading Node.js to `throw`
  a `Can't render headers after they are sent to the client.` error.
 
 ## Rule Details

docs/rules/handle-callback-err.md

@@ -1,6 +1,6 @@
 # Enforce Callback Error Handling (handle-callback-err)
 
-In node, a common pattern for dealing with asynchronous behavior is called the callback pattern.
+In Node.js, a common pattern for dealing with asynchronous behavior is called the callback pattern.
 This pattern expects an `Error` object or `null` as the first argument of the callback.
 Forgetting to handle these errors can lead to some really strange behavior in your application.
 
@@ -12,7 +12,7 @@ function loadData (err, data) {
 
 ## Rule Details
 
-This rule expects that when you're using the callback pattern in node you'll handle the error and
+This rule expects that when you're using the callback pattern in Node.js you'll handle the error and
 requires that you specify the name of your error object. The name of the argument will default to `err`.
 
 The following are considered problems:

docs/rules/no-comma-dangle.md

@@ -49,4 +49,4 @@ foo({
 
 ## When Not To Use It
 
-If your code will not be run in IE8 or below (a NodeJS application, for example) and you'd prefer to allow trailing commas, turn this rule off.
+If your code will not be run in IE8 or below (a Node.js application, for example) and you'd prefer to allow trailing commas, turn this rule off.

docs/rules/no-mixed-requires.md

@@ -1,6 +1,6 @@
 # Disallow Mixed Requires (no-mixed-requires)
 
-In the Node.JS community it is often customary to separate the `require`d modules from other variable declarations, sometimes also grouping them by their type. This rule helps you enforce this convention.
+In the Node.js community it is often customary to separate the `require`d modules from other variable declarations, sometimes also grouping them by their type. This rule helps you enforce this convention.
 
 ## Rule Details
 
@@ -115,10 +115,10 @@ var async = require('async'),
 
 ## Known Limitations
 
-* The implementation is not aware of any local functions with the name `require` that may shadow Node's global `require`.
+* The implementation is not aware of any local functions with the name `require` that may shadow Node.js' global `require`.
 
-* Internally, the list of core modules is retrieved via `require("repl")._builtinLibs`. If you use different versions of Node.JS for ESLint and your application, the list of core modules for each version may be different.
-  The above mentioned `_builtinLibs` property became available in 0.8, for earlier versions a hardcoded list of module names is used as a fallback. If your version of Node is older than 0.6 that list may be inaccurate.
+* Internally, the list of core modules is retrieved via `require("repl")._builtinLibs`. If you use different versions of Node.js for ESLint and your application, the list of core modules for each version may be different.
+  The above mentioned `_builtinLibs` property became available in 0.8, for earlier versions a hardcoded list of module names is used as a fallback. If your version of Node.js is older than 0.6 that list may be inaccurate.
 
 ## When Not To Use It
 

docs/rules/no-restricted-imports.md

@@ -4,7 +4,7 @@ Imports are an ES6/ES2015 standard for making the functionality of other modules
 
 Why would you want to restrict imports?
 
-* Some imports might not make sense in a particular environment. For example, Node's `fs` module would not make sense in an environment that didn't have a file system.
+* Some imports might not make sense in a particular environment. For example, Node.js' `fs` module would not make sense in an environment that didn't have a file system.
 
 * Some modules provide similar or identical functionality, think `lodash` and `underscore`. Your project may have standardized on a module. You want to make sure that the other alternatives are not being used as this would unnecessarily bloat the project and provide a higher maintenance cost of two dependencies when one would suffice.
 

docs/rules/no-restricted-modules.md

@@ -1,6 +1,6 @@
-# Disallow Node modules (no-restricted-modules)
+# Disallow Node.js modules (no-restricted-modules)
 
-Disallowing usage of specific node modules can be useful if you want to control the available methods, a developer can
+Disallowing usage of specific Node.js modules can be useful if you want to control the available methods, a developer can
 use, to implement a feature.
 
 This way you can block usage of the `fs` module if you want disallow file system access.