深入浅出Node.js开发指南

需积分: 9 24 浏览量更新于2024-07-18 收藏 3.06MB PDF 举报

"Pro Node.js for Developers_1st ed. Edition" 本书《Pro Node.js for Developers》是第一版，旨在向开发者全面介绍Node.js这一强大的异步开发框架。自2009年诞生以来，Node.js已成为构建高可扩展性网络应用的首选工具，被包括Dow Jones和LinkedIn在内的知名公司采纳。书中首先介绍了Node.js的基本概念，解释了它是什么、为什么重要以及如何设置。接着，作者深入探讨了支撑Node.js运行的关键概念和API。利用读者已有的JavaScript技能，书中指导如何使用Node.js构建Web和网络应用，处理数据源，捕获事件，并管理子进程，从而创建出能在各种情况下稳定运行的强健应用。随着技能的提升，书中进一步教授高级软件工程技巧，帮助代码实现专业化的提升。学习如何创建可复用模块，以节省代码编写时间；如何快速有效地进行日志记录和调试应用程序；以及如何编写能够随着应用需求增长而轻松扩展和可靠运行的代码。书中的章节结构清晰，涵盖了以下内容： - 第1章：入门，引导读者进入Node.js的世界。 - 第2章：Node模块系统，讲解Node.js的模块化设计。 - 第3章：Node编程模型，阐述Node.js的核心编程理念。 - 第4章：事件和定时器，讨论如何在Node.js中处理事件和时间管理。 - 第5章：命令行界面，介绍与命令行交互的方法。 - 第6章：文件系统，讲解如何操作文件和目录。 - 第7章：流，介绍Node.js中的流概念及其应用。 - 第8章：二进制数据，讨论处理非文本数据的方式。 - 第9章：执行代码，讲述运行外部脚本和程序的方法。 - 第10章：网络编程，涵盖网络连接和通信的基础。 - 第11章：HTTP，深入解析HTTP协议在Node.js中的实现。 - 第12章：Express框架，介绍流行的Node.js Web开发框架。 - 第13章：实时Web，探讨WebSocket等技术在实时通信中的应用。 - 第14章：数据库，讲解如何与各种数据库集成。 - 第15章：日志、调试和测试，提供监控和优化应用的策略。 - 第16章：应用扩展，讨论如何确保应用在高负载下仍能正常运行。 - 附录A：JSON，简要介绍JavaScript对象表示法及其在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页未读，继续阅读

xuanguang001

粉丝: 0
资源: 56

深入浅出Node.js开发指南

Pro Node.js for Developers

Node.js Design Patterns_Second Edition

Node.js英文书籍2015出版共9本(一次下载)

eclipse配置node.js

self.extraction.progress.show_progress.called

webpack < 5 used to include polyfills for node.js core modules by default

/common/category-cascader in ./node_modules/babel-loader/lib!./node_modules/vue-loader/lib/selector.js?

node.js 豆包api

node.js status

最新资源