diff --git a/docs/rules/README.md b/docs/rules/README.md index 758e5091faa..bf31bcb0653 100644 --- a/docs/rules/README.md +++ b/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 diff --git a/docs/rules/callback-return.md b/docs/rules/callback-return.md index 730294e0483..c7da9f5c35e 100644 --- a/docs/rules/callback-return.md +++ b/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 diff --git a/docs/rules/handle-callback-err.md b/docs/rules/handle-callback-err.md index 6d64de6c92f..39996b2bda8 100644 --- a/docs/rules/handle-callback-err.md +++ b/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: diff --git a/docs/rules/no-comma-dangle.md b/docs/rules/no-comma-dangle.md index 7ae2777416a..9e089c09d67 100644 --- a/docs/rules/no-comma-dangle.md +++ b/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. diff --git a/docs/rules/no-mixed-requires.md b/docs/rules/no-mixed-requires.md index cf058832c37..d0bc4024179 100644 --- a/docs/rules/no-mixed-requires.md +++ b/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 diff --git a/docs/rules/no-restricted-imports.md b/docs/rules/no-restricted-imports.md index 19f381f68be..d37d6b7bb02 100644 --- a/docs/rules/no-restricted-imports.md +++ b/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. diff --git a/docs/rules/no-restricted-modules.md b/docs/rules/no-restricted-modules.md index a872c76677d..bfeb11fee86 100644 --- a/docs/rules/no-restricted-modules.md +++ b/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.