Merge pull request #316 from webpack/spelling/node-js

Replace node.js with Node.js

Author: sokra

content/concepts/targets.md

@@ -26,10 +26,10 @@ module.exports = config;
 
 The following is a list of values you can pass to the `target` property.
 
-* `"async-node"` Compile for usage in a node.js-like environment (use `fs` and `vm` to load chunks async)
+* `"async-node"` Compile for usage in a Node.js-like environment (use `fs` and `vm` to load chunks async)
 * `"electron-main"` Compile for electron renderer process, provide a target using `JsonpTemplatePlugin`, `FunctionModulePlugin` for browser environment and `NodeTargetPlugin` and `ExternalsPlugin` for commonjs and electron bulit-in modules. *Note: need `webpack` >= 1.12.15.
-* `"node"` Compile for usage in a node.js-like environment (uses node.js `require` to load chunks)
-* `"node-webkit"` Compile for usage in webkit, uses jsonp chunk loading but also supports build in node.js modules plus require("nw.gui") (experimental)
+* `"node"` Compile for usage in a Node.js-like environment (uses Node.js `require` to load chunks)
+* `"node-webkit"` Compile for usage in webkit, uses jsonp chunk loading but also supports build in Node.js modules plus require("nw.gui") (experimental)
 * `"web"` Compile for usage in a browser-like environment (default)
 * `"webworker"` Compile as WebWorker
 

content/configuration/index.md

@@ -32,7 +32,7 @@ T> Notice that throughout the configuration we use Node's built-in [path module]
 
     [path](/configuration/output#output-path): path.resolve(__dirname, "dist"), // string
     // the target directory for all output files
-    // must be an absolute path (use the node.js path module)
+    // must be an absolute path (use the Node.js path module)
 
     <details><summary>[filename](/configuration/output#output-filename): "bundle.js", // string</summary>
     [filename](/configuration/output#output-filename): "[name].js", // for multiple entry points
@@ -299,8 +299,8 @@ T> Notice that throughout the configuration we use Node's built-in [path module]
 
   <details><summary>[target](/configuration/target): "web", // enum</summary>
   [target](/configuration/target): "webworker", // WebWorker
-  [target](/configuration/target): "node", // node.js via require
-  [target](/configuration/target): "async-node", // node.js via fs and vm
+  [target](/configuration/target): "node", // Node.js via require
+  [target](/configuration/target): "async-node", // Node.js via fs and vm
   [target](/configuration/target): "node-webkit", // nw.js
   [target](/configuration/target): "electron-main", // electron, main process
   [target](/configuration/target): "electron-renderer", // electron, renderer process

content/configuration/node.md

@@ -23,4 +23,4 @@ node: {
 }
 ```
 
-?> Elaborate on this section. What does "mock" or "empty" do? Does `<node builtin>` in the current documentation mean you can enable, disable, or polyfill any global node functions? (it seems `setImmediate` is the example for that)
+?> Elaborate on this section. What does "mock" or "empty" do? Does `<node builtin>` in the current documentation mean you can enable, disable, or polyfill any global Node.js function? (it seems `setImmediate` is the example for that)

content/configuration/resolve.md

@@ -159,14 +159,14 @@ For example, the `package.json` of [D3](https://d3js.org/) contains these fields
 ```js
 {
   ...
-  main: 'build/d3.node.js',
+  main: 'build/d3.Node.js',
   browser: 'build/d3.js',
   module: 'index',
   ...
 }
 ```
 
-This means that when we `import * as D3 from "d3"` this will really resolve to the file in the `browser` property. The `browser` property takes precedence here because it's the first item in `mainFields`. Meanwhile, a node application bundled by webpack will resolve by default to the file in the `module` field.
+This means that when we `import * as D3 from "d3"` this will really resolve to the file in the `browser` property. The `browser` property takes precedence here because it's the first item in `mainFields`. Meanwhile, a Node.js application bundled by webpack will resolve by default to the file in the `module` field.
 
 
 ## `resolve.mainFiles`

content/configuration/target.md

@@ -22,7 +22,7 @@ Tell webpack what environment the application is targeting. The following option
 `target: "webworker"` - Compile as a [WebWorker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API)
 
 
-T> Allows importing of built-in node modules and [`nw.gui`](http://docs.nwjs.io/en/latest/) (experimental).
+T> Allows importing of built-in Node.js modules and [`nw.gui`](http://docs.nwjs.io/en/latest/) (experimental).
 
 `target: "async-node"` - Use `fs` and `vm` to load chunks asynchronously
 

content/how-to/author-libraries.md

@@ -138,7 +138,7 @@ This means that your library expects a dependency named `lodash` to be available
 
 ### Add `libraryTarget`
 
-For widespread use of the library, we would like it to be compatible in different environments, ie CommonJs, AMD, nodejs and as a global variable.
+For widespread use of the library, we would like it to be compatible in different environments, i. e. CommonJs, AMD, Node.js and as a global variable.
 
 To make your library available for reuse, add `library` property in webpack configuration.
 

content/how-to/cache.md

@@ -135,7 +135,7 @@ A sample output of webpack-manifest-plugin for our config looks like:
 }
 ```
 
-The rest depends on your server setup. There is a nice [walk through for Rails-based projects](http://clarkdave.net/2015/01/how-to-use-webpack-with-rails/#including-precompiled-assets-in-views). For serverside rendering in node you can use [webpack-isomorphic-tools](https://github.com/halt-hammerzeit/webpack-isomorphic-tools). Or, if your application doesn’t rely on any server-side rendering, it’s often enough to generate a single `index.html` file for your application. To do so, just use these 2 amazing plugins:
+The rest depends on your server setup. There is a nice [walk through for Rails-based projects](http://clarkdave.net/2015/01/how-to-use-webpack-with-rails/#including-precompiled-assets-in-views). For serverside rendering in Node.js you can use [webpack-isomorphic-tools](https://github.com/halt-hammerzeit/webpack-isomorphic-tools). Or, if your application doesn’t rely on any server-side rendering, it’s often enough to generate a single `index.html` file for your application. To do so, just use these 2 amazing plugins:
 
 * https://github.com/ampedandwired/html-webpack-plugin
 * https://github.com/szrenwei/inline-manifest-webpack-plugin

content/how-to/generate-production-build.md

@@ -20,9 +20,9 @@ One of the good options to go is using `cheap-module-source-map` which simplifie
 
 ## Node environment variable
 
-The second step is to tell webpack to generate a production build by setting the node environment variable to `production`. webpack will not include any extra useful code, warnings and checks used in development.
+The second step is to tell webpack to generate a production build by setting the Node.js environment variable to `production`. webpack will not include any extra useful code, warnings and checks used in development.
 
-The `DefinePlugin` creates **compile** time constants. Useful for injecting your node environment as seen below.
+The `DefinePlugin` creates **compile** time constants. Useful for injecting your Node.js environment as seen below.
 
 ?> TODO: Add a link to the `ProvidePlugin` documentation