深入理解Node.js开发：高级编程技术解析

需积分: 4 194 浏览量更新于2024-07-24 收藏 3.04MB PDF 举报

"《Pro Node.js for Developers》是面向JavaScript高级编程技术的一本书，由Apress出版。本书详细介绍了Node.js的各种核心概念和技术，包括模块系统、编程模型、事件和定时器、命令行接口、文件系统、流、二进制数据、代码执行、网络编程、HTTP协议、Express框架、实时Web通信、数据库操作、日志记录、调试和测试以及应用扩展等。书中有作者简介、技术审阅者介绍、致谢、目录、引言和附录，还提供了方便的书签和内容概览链接。" 《Pro Node.js for Developers》这本书全面覆盖了Node.js开发的关键知识点，首先在"Getting Started"章节，读者将了解到如何入门Node.js，包括安装环境、基本用法和构建第一个Node.js程序，帮助初学者快速上手。接着，"The Node Module System"章节深入讲解了Node.js的模块系统，这是理解Node.js程序结构的基础，包括模块的导入与导出机制、内置模块和第三方模块的使用。 "Chapter3: The Node Programming Model"介绍了Node.js独特的非阻塞I/O模型，以及事件驱动编程的概念，这是Node.js性能高效的关键所在。 "Events and Timers"章节探讨了事件循环和定时器，学习如何正确使用setTimeout和setInterval等API来控制程序的时间行为。 "Chapter5: The Command Line Interface"和"Chapter6: The FileSystem"则分别讲述了Node.js的命令行接口和文件系统操作，包括读写文件、目录管理和文件监控等实用功能。 "Chapter7: Streams"是Node.js处理大量数据的核心工具，通过流可以高效地处理大文件和网络数据。 "Chapter8: Binary Data"讲解了如何处理二进制数据，如图片、音频或视频，这对于构建多媒体应用至关重要。 "Chapter9: Executing Code"涵盖了子进程管理和进程间通信，让开发者了解如何在Node.js中运行其他程序和管理进程。 "Chapter10: Network Programming"和"Chapter11: HTTP"详细解析了网络编程和HTTP协议，使开发者能够构建服务器端应用程序和Web服务。 "Chapter12: The Express Framework"介绍了流行的Express框架，它是构建RESTful API和Web应用的常用工具。 "Chapter13: The Real-Time Web"探讨了WebSocket等实时通信技术，适用于创建聊天应用、游戏和实时数据更新场景。 "Chapter14: Databases"涵盖了Node.js与数据库的交互，包括SQL和NoSQL数据库的连接和操作。 "Chapter15: Logging, Debugging, and Testing"教导读者如何进行日志记录、调试和编写测试用例，确保代码质量和可维护性。最后，"Chapter16: Application Scaling"讨论了如何优化和扩展Node.js应用，以应对高并发和大规模用户需求。附录A介绍了JSON（JavaScript Object Notation）这种轻量级的数据交换格式，它是Node.js中常见的数据存储和传输方式。《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页未读，继续阅读

kumikoda

粉丝: 0
资源: 3

深入理解Node.js开发：高级编程技术解析

Apress.Pro.Node.js.for.Developers.Nov.2013.rar

帮我找一下可以写再javaweb毕设里的英文参考文献

javascript相关外文文献

html5的网页设计与制作研究参考文献

关于springboot的英文文献

列举几个SpringBoot相关的技术文献,以文献引用的格式展示

spring boot项目英文文献

springboot的参考文献

springboot参考文献

springboot框架外文参考文献列表

最新资源