精通Node.js：开发者的全面指南

需积分: 10 99 浏览量更新于2024-07-22 收藏 3.06MB PDF 举报

"Pro Node.js for Developers" 是一本专为专业开发人员编写的指南，深入探讨了Node.js这一强大的JavaScript开发框架。自2009年成立以来，Node.js凭借其异步编程特性，在构建高度可扩展的网络应用方面展现出了显著的优势，众多知名企业如Dow Jones和LinkedIn都已将其融入业务中，看到了其潜力。本书首先对Node.js进行了全面的介绍，解释其核心概念、重要性以及如何安装和配置，确保读者对这个新兴技术有深刻的理解。它旨在帮助那些拥有JavaScript基础的开发者，通过学习如何利用Node.js构建网络应用和Web应用，掌握处理数据源、捕获事件以及管理子进程等关键技能，从而打造能在各种环境下稳定运行的复杂应用程序。书中进一步深化了软件工程实践，教授更高级的技术和最佳实践，包括模块化设计、错误处理、并发编程以及与后端数据库和API的集成。这些内容将帮助开发者提升他们的项目架构能力，适应现代互联网服务的需求，提高开发效率并提升产品质量。 "Pro Node.js for Developers"是一本实用且全面的指南，不仅适合希望转型或深入学习Node.js的开发者，也适合那些寻求在Node.js平台上优化现有项目的专业人士。通过阅读这本书，读者能够建立起坚实的Node.js开发基础，并在实际工作中灵活运用所学知识，推动项目的成功实施。

CHAPTER 2 ■ THE NODE MODULE SYSTEM

Note ■ You do not need to understand git and GitHub to use Node. However, most Node modules use the GitHub

ecosystem for source control and bug tracking. Although GitHub and its use are well outside the scope of this book, it is

highly advisable to become familiar with it.

Listing 2-6. git URL Formats Supported by npm

git://github.com/user/project.git#commit-ish

git+ssh://user@hostname:project.git#commit-ish

git+ssh://user@hostname/project.git#commit-ish

git+http://user@hostname/project/blah.git#commit-ish

git+https://user@hostname/project/blah.git#commit-ish

Packages can also be installed from tarball URLs. For example, to install the master branch of a GitHub repository,

use the syntax shown in Listing 2-7. Though this URL does not point to an actual repository, you can experiment by

downloading the commander module: https://github.com/visionmedia/commander.js/tarball/master.

Listing 2-7. Installing a Tarball from a GitHub Repository

$ npm install https://github.com/user/project/tarball/master

Package Locations

When packages are installed, they are saved somewhere on your local machine. Typically, this location is a

subdirectory named node_modules within your current directory. To determine the location, use the command npm

root. You can also view all the installed modules using the npm ls command. After installing the commander module,

you can verify that it exists using npm ls. For the purposes of this example, install version 1.3.2. Listing 2-8 shows

that commander version 1.3.2 is installed. Also, notice that a module named keypress is installed. The tree structure

indicates that commander depends on the keypress module. Since npm is able to recognize this dependency,

it automatically installs any required modules.

Listing 2-8. Listing All of the Currently Installed Packages Using npm ls

$ npm ls

/home/colin/npm-test

└─┬ commander@1.3.2

└── keypress@0.1.0

You can also see the installed modules by browsing the node_modules subdirectory. In this example, commander

is installed in node_modules/commander, and keypress is installed in node_modules/commander/node_modules/

keypress. If keypress had any dependencies, they would be installed in yet another node_modules subdirectory

under the keypress directory.

Global Packages

Packages, as described thus far, are libraries that are included in your program. Referred to as local packages, these must

be installed in every project using them. Another type of package, known as a global package, needs to be installed

in only one location. Although global packages typically do not include code libraries, they can. As a rule of thumb,

global packages normally contain command line tools, which should be included in the PATH environment variable.

CHAPTER 2 ■ THE NODE MODULE SYSTEM

To install a package globally, simply issue npm install with the -g or --global option. In fact, you can process

global packages by adding the -g option to most npm commands. For example, you can view the installed global

packages by issuing the command npm ls -g. You can also locate the global node_modules folder using the

npm root -g command.

Linking Packages

Using npm, you can create links to local packages. When you link to a package, it can be referenced as if it were a global

package. This is especially useful if you are developing a module and want another project to reference your local

copy of the module. Linking is also useful if you want to deploy your module without publishing it to the public

npm registry.

Package linking is a two-step process. The first step, creating the link, is done by changing to the directory of the

project you want to make linkable. Listing 2-9 shows how to create a link to your module, assuming that your module

is located in foo-module. After executing the npm link command, verify that the link was created using npm ls -g.

Listing 2-9. Creating a Link Using npm link

$ cd foo-module

$ npm link

The second step in module linking, actually referencing the link, is very similar to a package installation.

First, change to the directory of the project that will import the linked module. Next, issue another npm link command.

However, this time you must also specify the linked module’s name. An example of this procedure is shown in

Listing 2-10. In the example, the foo-module link from Listing 2-9 is referenced from a second module, bar-module.

Listing 2-10. Referencing an Existing Link Using npm link

$ cd bar-module

$ npm link foo-module

Unlinking Packages

The process for removing linked modules is very similar to the process for creating them. To remove a linked module

from an application, use the npm unlink command, followed by the name. Listing 2-11 shows the command for

removing the linked foo-module from bar-module.

Listing 2-11. Removing a Reference to a Link Using npm unlink

$ cd bar-module

$ npm unlink foo-module

Similarly, to remove a link from your system, change to the linked module’s directory, and issue the npm unlink

command. Listing 2-12 shows how to remove the foo-module link.

Listing 2-12. Removing a Linked Module Using npm unlink

$ cd foo-module

$ npm unlink

CHAPTER 2 ■ THE NODE MODULE SYSTEM

Updating Packages

Since any package that is actively developed eventually releases a new version, your copy will become outdated.

To determine if your copy is out of date, run npm outdated in your project directory (see Listing 2-13). In the example,

which assumes that an outdated version 1.0.0 of commander is installed, npm indicates that the latest version is 2.0.0

but that your copy is only 1.0.0. Listing 2-13 checks all of the local packages. You can check individual packages by

specifying their names, and you can process global packages by specifying the -g option.

Listing 2-13. Displaying Outdated Packages Using npm outdated

$ npm outdated

npm http GET https://registry.npmjs.org/commander

npm http 304 https://registry.npmjs.org/commander

commander@2.0.0 node_modules/commander current=1.0.0

To update any outdated local packages, use the npm update command. Much like outdated, update works on all

local packages by default. Again, you can target individual modules by specifying their names. You can also update

global packages using the -g option. In Listing 2-14, npm updates itself using the -g option.

Listing 2-14. Updating npm Using npm update

$ npm update npm -g

Uninstalling Packages

To remove a package, use either the npm uninstall or npm rm command (the two commands can be used

interchangeably), and specify one or more packages to be removed. You can also remove global packages by providing

the -g option. Listing 2-15 shows how to remove the commander module using npm rm.

Listing 2-15. Uninstalling commander Using npm rm

$ npm rm commander

The require() Function

As shown in the previous section, Node packages are managed using npm. However, to import modules into your

programs, the require() function is used. require() accepts a single argument, a string specifying the module to

load. If the specified module path exists, require() returns an object that can be used to interface with the module.

If the module cannot be located an exception is thrown. Listing 2-16 shows how the commander module is imported

into a program using the require() function.

Listing 2-16. Using the require() Function

var commander = require("commander")

Core Modules

Core modules are modules compiled into the Node binary. They are given the highest precedence by require(),

meaning that in the event of a module-naming conflict, the core module is loaded. For example, Node contains a core

module named http, which, as the name implies, provides features for working with the Hypertext Transfer Protocol

(HTTP). No matter what, a call to require("http") will always load the core http module. As a side note, the core

modules are located in the lib directory of the Node source code.

CHAPTER 2 ■ THE NODE MODULE SYSTEM

File Modules

File modules are non-core modules loaded from the file system. They can be specified using absolute paths, relative

paths, or from the node_modules directory. Module names that begin with a slash (/) are treated as absolute paths.

For example, in Listing 2-17, a file module, foo, is loaded using an absolute path.

Listing 2-17. A File Module Import Using an Absolute Path

require("/some/path/foo");

Caution ■ Some operating systems such as Windows use a case-insensitive file system. This allows you to write

require("commander"), require("COMMANDER"), or require("CoMmAnDeR"). However, on a case-sensitive file system

such as Linux, the last two calls would fail. Therefore, you should assume case sensitivity, no matter what operating

system you're using.

Node also supports Windows-style file paths. On Windows, Node allows the slash and backslash characters

(/ and \) to be used interchangeably. For the sake of consistency, and to avoid escaping the backslash character, this

book primarily uses Unix-style paths. However, be aware that all the paths shown in Listing 2-18 are valid on Windows.

Listing 2-18. Example Module Paths Valid on Windows

require("/some/path/foo");

require("C:/some/path/foo");

require("C:\\some\\path\\foo");

require("\\some/path\\foo");

Module paths that begin with one or two dots (. or ..) are interpreted as relative paths—that is, they are

considered relative to the file that called require(). Listing 2-19 shows three examples of relative module paths.

In the first example, foo is loaded from the same directory as the calling script. In the second, foo is located in the

calling script’s parent directory. In the third, foo is located in a subdirectory, sub, of the calling script’s directory.

Listing 2-19. Example Module Imports Using Relative Paths

require("./foo");

require("../foo");

require("./sub/foo");

If a module path does not correspond to a core module, an absolute path, or a relative path, then Node

begins searching in node_modules folders. Node begins with the calling script’s parent directory and appends

/node_modules. If the module is not found, Node moves one level up the directory tree, appends /node_modules, and

searches again. This pattern is repeated until the module is located or the root of the directory structure is reached.

The example in Listing 2-20 assumes that a project is located in /some/path and shows the various node_modules

directories that would be searched, in order.

Listing 2-20. Example of the Search Order of node_modules Directories

/some/path/node_modules

/some/node_modules

/node_modules

CHAPTER 2 ■ THE NODE MODULE SYSTEM

File Extension Processing

If require() does not find an exact match, it attempts to add .js, .json, and .node file extensions. As mentioned in

Chapter 1, .js files are interpreted as JavaScript source code, .json files are parsed as JSON source, and .node files are

treated as compiled add-on modules. If Node is still unable to find a match, an error is thrown.

It is also possible to programmatically add support for additional file extensions using the built-in require.extensions

object. Initially, this object contains three keys, .js, .json, and .node. Each key maps to a function that defines

how require() imports files of that type. By extending require.extensions, you can customize the behavior of

require(). For example, Listing 2-21 extends require.extensions such that .javascript files are treated as .js files.

Listing 2-21. Extending the require.extensions Object to Support Additional File Types

require.extensions[".javascript"] = require.extensions[".js"];

You can even add custom handlers. In Listing 2-22, .javascript files cause require() to print data about the

imported file to the console.

Listing 2-22. Adding a Custom Handler to the require.extensions Object

require.extensions[".javascript"] = function() {

console.log(arguments);

};

Caution ■ Though this feature has recently been deprecated, the module system API is locked, so require.extensions

is unlikely to ever disappear completely. The official documentation recommends wrapping non-JavaScript modules in

another Node program or compiling them to JavaScript a priori.

Resolving a Module Location

If you are interested only in learning where a package is located, use the require.resolve() function, which uses

the same mechanism as require() to locate modules. However, instead of actually loading the module, resolve()

only returns the path to the module. If the module name passed to resolve() is a core module, the module’s name

is returned. If the module is a file module, resolve() returns the module’s file name. If the Node cannot locate the

specified module, an error is thrown. The example in Listing 2-23 shows usage of resolve() in the REPL environment.

Listing 2-23. Locating the http Module Using require.resolve()

> require.resolve("http");

'http'

Module Caching

A file module that is loaded successfully is cached in the require.cache object. Subsequent imports of the same

module return the cached object. One caveat is that the resolved module path must be exactly the same. This is so

because a module is cached by its resolved path. Therefore, caching becomes a function of both the imported module

and the calling script. Let’s say your program depends on two modules, foo and bar. The first module, foo, has no

dependencies, but bar depends on foo. The resulting dependency hierarchy is shown in Listing 2-24. Assuming

that foo resides in the node_modules directory, it is loaded twice. The first load occurs when foo is resolved to the

your-project/node_modules/foo directory. The second load occurs when foo is referenced from bar and resolves to

your-project/node_modules/foo/node_modules.

剩余294页未读，继续阅读

yhcharles

粉丝: 10
资源: 8

精通Node.js：开发者的全面指南

professional nodejs

NodeJS for Windows 32bit

NodeJS for mac

golang-for-nodejs-developers：将Golang与Node.js进行比较的示例以进行学习

nodejs for mac

egg_pro:nodejs egg pro

cabal-online-api:使用NodeJS for Cabal Online构建的API

nodejs-for-qa

kubernetes for developers

nodejs nodejs

最新资源