Node.js零起点开发(二)-require的用法
require最常用的方法
require('http') 内置模块
require('./server') “./”表示当前路径,后面跟的是相对路径
require("../lib/server") ../表示上一级目录,后面跟的也是相对路径
server.js
模块Node 使用 CommonJS 模块系统。
Node 有一个简单的模块加载系统。在 Node 中,文件和模块一一对应。比如,在
foo.js加载同一目录中的circle.js模块。
foo.js的内容:var circle = ('./circle.js');console.( 'The area of a circle of radius 4 is ' + circle.(4));
circle.js的内容:var PI = .PI;exports.area = function (r) { return PI * r * r;};exports.circumference = function (r) { return 2 * PI * r;};模块
circle.js导出了area()函数和circumference()函数,这样它们就能从模块外部访问了。要导出对象,将其添加到特殊的exports对象就行。模块的局部变量是私有的。在本例中,变量
PI是circle.js私有的。核心模块
Node 有一些已编译成二进制的模块,这些模块将在本文档的其他地方详细??介绍。
核心模块在 Node 源代码的
lib/文件夹中定义。使用
require()时,核心模块总是优先加载。例如,require('http')总是返回内置的 HTTP 模块,即使该名称的文件存在。文件模块
如果没有找到确切的文件,Node 将尝试给所需的文件名??添加
.js后缀再加载,然后再尝试.node。
.js文件被视为 JavaScript 文本文件,而.node文件被视为已编译的插件模块,用dlopen加载。模块以
'/'开头表示使用文件的绝对路径。例如,require('/home/marco/foo.js')将加载/home/marco/foo.js文件。模块以
'./'开头表示调用require()时使用相对路径。也就是说,为了保证require('./circle')能找到,circle.js必须和foo.js在同一目录。如果不以 '/' 或'./' 开头,该模块可以是一个“核心模块”,也可是一个从
node_modules文件夹中加载的模块。从 `node_modules` 文件夹中加载
如果传递给
require()有模块标识符是不是原生模块,而且不以'/'、'../'或'./'开头,那么 Node 从当前模块的父目录+/node_modules这个位置尝试加载。如果还是没有找到,那么它跳到上层目录并依此类推,直到找到模块,或者达到根目录为止。
例如,如果在文件
'/home/ry/projects/foo.js'中调用require('bar.js'),那么 Node 将在下列位置查找,顺序如下:
/home/ry/projects/node_modules/bar.js/home/ry/node_modules/bar.js/home/node_modules/bar.js/node_modules/bar.js这就允许程序将依赖关系本地化,防止它们冲突。
当嵌套依赖关系的层次很深时,这个文件查找列表可能会变得很长。因此,在查找时进行如下优化:
首先,/node_modules 不会附加到一个以 /node_modules 结尾的文件夹后面。
其次,如果调用 require() 的文件已经在一个 node_modules 层级里,那么最顶层的 node_modules 文件夹将被视为搜索树的根。
例如,如果在文件 '/home/ry/projects/foo/node_modules/bar/node_modules/baz/quux.js' 中调用require('asdf.js'),那么 Node 将搜索下列位置:
/home/ry/projects/foo/node_modules/bar/node_modules/baz/node_modules/asdf.js/home/ry/projects/foo/node_modules/bar/node_modules/asdf.js/home/ry/projects/foo/node_modules/asdf.jsNode 允许用户在独立的目录中方便地组织程序,然后提供单一入口指向该库。有三种方式可以将文件夹作为require() 的参数。
第一种方式是在该文件夹中创建 package.json 文件,指定一个 main 模块。一个典型的 package.json 文件可能看起来像这样:
{ "name" : "some-library", "main" : "./lib/some-library.js" }如果此文件位于 ./some-library 文件夹,则 require('./some-library') 会尝试加载 ./some-library/lib/some-library.js。
这是 Node 能找到 package.json 文件的情况。
如果在该目录中没有 package.json 文件,那么 Node 将尝试加载该目录中的 index.js 或 index.node 文件。例如,如果上面的例子找不到 package.json,那么 require('./some-library') 将试图加载:
./some-library/index.js./some-library/index.node模块在首次被加载后会缓存起来。这意味着每次调用 require('foo') 将得到完全相同的对象,如果它被解析为同一个文件的话。
为了得到调用 require() 时被载入的确切的文件名,使用 require.resolve() 函数。
综上所述,这是 require.resolve 的伪码描述:
(X)1. If X is a core module, a. return the core module b. STOP2. If X begins with `./` or `/`, a. (Y + X) b. (Y + X)3. (X, (Y))4. THROW "not found"(X)1. If X is a file, load X as JavaScript text. STOP2. If X.js is a file, load X.js as JavaScript text. STOP3. If X.node is a file, load X.node as binary addon. STOP(X)1. If /package.json is a file, a. Parse /package.json, and look for "main" field. b. let M = X + (json main field) c. (M)2. (/index)(X, START)1. let DIRS=(START)2. for each DIR in DIRS: a. (/X) b. (/X)(START)1. let PARTS = path (START)2. let ROOT = index of first instance of "node_modules" in PARTS, or 03. let I = count of PARTS - 14. let DIRS = []5. while I > ROOT, a. if PARTS[I] = "node_modules" CONTINUE c. DIR = path (PARTS[0 .. I] + "node_modules") b. DIRS = DIRS + DIR6. return DIRS在 Node 中,require.paths 是一个字符串数组,表示模块不以 '/' './' 或 '..' 打头的搜索路径。例如,如果 require.paths 设置为:
[ '/home/micheil/.node_modules', '/usr/local/lib/node_modules' ]则调用 require('bar/baz.js') 会搜索以下位置:
'/home/micheil/.node_modules/bar/baz.js'2: '/usr/local/lib/node_modules/bar/baz.js'可以在运行时修改 require.paths 数组来改变这种行为。
它的值最初从 NODE_PATH 环境变量而来,那是一个冒号分隔的绝对路径列表。在前面的例子中,NODE_PATH 环境变量可能被设置为:
/home/mi/.node_modules:/usr///node_modules只有使用上面的 node_modules 算法找不到模块时才会尝试 require.paths。全局模块的优先级低于捆绑依赖。
出于兼容性的考虑,require.paths 仍然是模块查找过程的首选策略。尽管如此,它可能会在将来的版本中废弃。
虽然它看起来似乎是个好主意,但在实践中一个可变的 require.paths 列表往往是麻烦和混乱的根源。
这行代码并不会像期望的那样:
require.paths = [ '/usr/lib/node' ];它的结果就是丢弃了 Node 实际的模块查找路径引用,并创建了一个毫无用处的指向别处的新的引用。
如果你这样做:
require.paths.('./lib');它不会添加 ./lib 在文件系统上已解析的完整路径。相反,它实际增加的是 './lib',这意味着如果你在/a/b/x.js 中 require('y.js'),那么它会查找 /a/b/lib/y.js。如果你之后又在 /l/m/n/o/p.js 中require('y.js'),那么它就会查找 /l/m/n/o/lib/y.js。
在实践中,人们往往将它作为捆绑依赖的临时解决办法,这个技巧是不太稳妥的。
有一种糟糕的设计:所有模块共用一个 require.paths 数组。
结果,如果一个 Node 程序依赖于这种行为,它可能会永久而微妙地改变同一进程中其它 Node 程序的行为。当应用程序的复杂度增加时,我们倾向于封装功能,这些行为很难预料的部分会成为开发者的恶梦。
在 Node 中,require() 函数的语义被设计成通用性足以支持大量合理的目录结构。因此 dpkg、rpm 和 npm之类的包管理器可以从 Node 模块构建原生包而不作更改。
下面我们给出一个可以工作的建议的目录结构:
比方说,我们希望 /usr/lib/node/<some-package>/<some-version> 文件夹中包含某个包的特定版本的内容。
一个软件包可以依赖别的包。为了安装 foo 包,你可能需要安装 bar 包的特定版本 。可能该 bar 包本身有依赖关系,在某些情况下,这些依赖关系甚至可能发生冲突或者形成回路。
由于 Node 在加载任何模块时都会查找它的真实路径(即:会解析符号链接),然后在 node_modules 文件夹用上文描述的方式查找依赖。使用以下架构可以很简单地解决:
/usr/lib/node/foo/1.2.3/ -foo 包的内容,版本1.2.3。/usr/lib/node/bar/4.3.2/ -bar 包的内容,foo 依赖这个包。/usr/lib/node/foo/1.2.3/node_modules/bar -到 /usr/lib/node/bar/4.3.2/ 的符号链接。/usr/lib/node/bar/4.3.2/node_modules/* -到 bar 所依赖的包的符号链接。因此,即使遇到一个回路,或者有依赖冲突,每个模块都能够得到它依赖的可用版本。
当 foo 包中有代码 require('bar') 时,它会得到符号链接至/usr/lib/node/foo/1.2.3/node_modules/bar 的版本。然后,当 bar 包调用 require('quux') 时,它会得到符号链接至 /usr/lib/node/bar/4.3.2/node_modules/quux 的版本。
此外,为了使模块查找过程更加优化,而??不是直接把包放到 /usr/lib/node 中,我们可以它们放到/usr/lib/node_modules/<name>/<version> 里。这样,Node 就不用在 /usr/node_modules 或/node_modules 中查找了。
为了使 REPL 能够正常引用模块,可以将 /usr/lib/node_modules 添加至 $NODE_PATH环境变量。因为使用node_modules 文件夹查找模块时的路径都是相对的,而且调用 require() 时基于文件的真实路径,因此软件包本身可以放在任何位置。