为什么 npm 要为每个项目单独安装一遍 node_modules？ - 知乎355被浏览31782分享邀请回答875 条评论分享收藏感谢收起216 条评论分享收藏感谢收起查看更多回答NodeJs的无参数环境引用module的问题 - CNode技术社区
这家伙很懒，什么个性签名都没有留下。
![K_K9O68F1NK84
我需要快速的测试underscore提供的方法的功能，但是我在自己的js文件里面写好再来node运行，总感觉这个操作很不必要。
进入到Node的无参数环境，发现却不能通过声明变量的方式来调用underscore，如上截图。感觉并不是每一次的&就是一次独立的上下文环境，我在上一次&里面如果是声明基本类型变量如 var a = ‘abc’，到下一次&都还是可以正常饮用啊。为什么引用类库却就不行了呢？
换个变量名也成：
& var u = require('underscore')
& u.shuffle([1,2,3])
[ 2, 3, 1 ]
CNode 社区为国内最专业的 Node.js 开源技术社区，致力于 Node.js 的技术研究。
服务器赞助商为
，存储赞助商为
，由提供应用性能服务。
新手搭建 Node.js 服务器，推荐使用无需备案的NodeJS学习笔记之Module的简介
作者：张亚涛
字体：[ ] 类型：转载 时间：
模块是Node.js 应用程序的基本组成部分，文件和模块是一一对应的。换言之，一个 Node.js 文件就是一个模块，这个文件可能是JavaScript 代码、JSON 或者编译过的C/C++ 扩展。
Node.js模块系统
Node.js有一个简单的模块加载系统。 在Node.js中，文件和模块是一一对应的（每个文件被视为单独的模块）。
例如，考虑下面这个名为 foo.js 的文件：
const circle = require('./circle.js');
console.log(`The area of a circle of radius 4 is ${circle.area(4)}`);
在第一行， foo.js 加载与 foo.js 同一目录的模块 circle.js 。
circle.js 的内容如下：
const PI = Math.PI;
exports.area = (r) =& PI * r *
exports.circumference = (r) =& 2* PI *
模块 circle.js 导出了函数 area() 和 circumference() 。 要将函数和对象添加到模块的根目录，可以将它们赋值到特殊 exports 对象上。
模块内部的变量一定是私有的，因为模块被Node.js包裹在一个函数中（参见下面的模块包装器）。 在这个例子中，变量 PI 对于 circle.js 来说是私有变量。
如果你希望模块导出的是一个函数（如构造函数），或者是要导出完整的对象，而不是一次创建一个属性，则需要将其分配给 module.exports 而不是 exports 。
在下面的 bar.js 中，使用了 square 模块，它导出一个构造函数：
const square = require('./square.js');
var mySquare = square(2);
console.log(`The area of my square is ${mySquare.area()}`);
在 square.js 模块中定义一个 square 方法:
module.exports = (width) =& {
area: () =& width *
此外，模块系统在 require(“module”) 模块中实现。
『main』模块
当某个 module 直接从Node.js运行时，它会将 require.main 设置该 module 。 你可以通过这个来测试这个 module 是被直接运行的还是被 require 的。
require.main === module
就拿文件 foo.js 来说，如果运行 node foo.js 这个属性就是 true 。运行 require('./foo.js') 就是 false 。
因为 module 提供了一个 filename （通常相当于 __filename ），因此可以通过检查 require.main.filename 来获取当前应用程序的入口点。
包管理器的一些提示
Node.js的 require() 函数支持一些合理的目录结构。它让软件包管理器程序（如 dpkg ， rpm 和 npm ）可以从Node.js模块中直接去构建本地的包而不需要修改。
下面我们给出一个可以正常工作的建议目录结构：
假设我们希望在 /usr/lib/node/&some-package&/&some-version& 中的文件夹来指定版本的包。
此外，包还可以相互依赖。 比如你想安装 foo 包，而这个包有可能需要安装指定版本的 bar 包。而 bar 包也很有可能依赖其他的包，并且在某些特殊情况下，这些依赖包甚至可能会产生循环依赖。
由于Node.js会查找加载的所有模块的 realpath （即解析软链），然后再去node_modules文件夹中查找依赖的包，因此使用以下方案可以非常简单地解决此问题：
/usr/lib/node/foo/1.2.3/ - 包含 foo 包，版本是 1.2.3
/usr/lib/node/bar/4.3.2/ - 包含 foo 所依赖的 bar 包
/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 。
模块加载的全过程（重点，下面写的伪代码流程一定要记住）
要获取在调用 require() 将被加载的确切文件名，请使用 require.resolve() 函数。
以下是模块加载的全过程以及 require.resolve 的解析过程：
// 加载X模块
require(X) from module at path Y
1. If X is a core module.
a. return the core module
2. If X begins with './' or '/' or '../'
a. LOAD_AS_FILE(Y + X)
b. LOAD_AS_DIRECTORY(Y + X)
3. LOAD_NODE_MODULES(X, dirname(Y))
4. THROW "not found"
// 加载X文件
// 加载过程：X -& X.js -& X.json -& X.node
LOAD_AS_FILE(X)
1. If [X] is a file, load [X] as JavaScript text. STOP
2. If [X.js] is a file, load [X.js] as JavaScript text. STOP
3. If [X.json] is a file, load [X.json] as JavaScript text. STOP
4. If [X.node] is a file, load [X.node] as JavaScript text. STOP
// 加载入口文件
// 加载过程：X -& X/index.js -& X/index.json -& X/index.node
LOAD_INDEX(X)
1. If [X/index.js] is a file, load [X/index.js] as JavaScript text. STOP
2. If [X/index.json] is a file, load [X/index.json] as JavaScript text. STOP
3. If [X/index.node] if a file, load [X/index.node] as JavaScript text. STOP
// 加载文件夹
LOAD_AS_DIRECTORY(X)
1. If [X/package.json] is a file.
a. Parse [X/package.json], and look for "main" field
b. let M = X + (json main field)
c. LOAD_AS_FILE(M)
d. LOAD_INDEX(M)
2. LOAD_INDEX(X)
// 加载node模块
LOAD_NODE_MODULES(X, START)
1. let DIRS = NODE_MODULES_PATHS(START)
2. for each DIR in DIRS;
a. LOAD_AS_FILE(DIR/X)
b. LOAD_AS_DIRECTORY(DIR/X)
// 列出所有可能的node_modules路径
NODE_MODULES_PATHS(START)
1. let PARTS = path split(START);
2. let I = count of PARTS - 1
3. let DIRS = []
4. while I & 0
a. If PARTS[I] = "node_modules" CONTINUE
b. DIR = path join(PARTS[0 ... I] + "node_modules")
c. DIRS = DIRS + DIR
d. let I = I -1
5. return DIRS
所有的模块都会在第一次加载之后被缓存起来。 这意味着你每次调用 require('foo') 将得到完全相同的对象。
对 require('foo') 的多次调用可能并不会多次执行该模块的代码。 这是一个重要的功能。 使用它，可以返回“partially done”对象，从而允许根据依赖关系一层一层地加载模块，即使这样做可能会导致循环依赖。
如果要让某个模块在每次被加载时都去执行代码，则需要 exports 一个函数，并调用该函数即可。
模块缓存注意事项
模块是基于其解析出来的文件名进行缓存。根据调用模块的路径，被调用的模块可能会解析出不同的文件名（从node_modules文件夹加载）。如果解析出来的是不同的文件，它不保证每次 require('foo') 总是返回相同的对象。
另外，在不区分大小写的文件系统或操作系统上，不同的解析文件名可以指向相同的文件，但缓存仍将它们视为不同的模块，并将重新加载该文件多次。 例如， require('./ foo') 和 require('./ FOO') 返回两个不同的对象，而不管 ./foo 和 ./FOO 是否是同一个文件。
Node.js有些模块被编译成二进制文件。 本文档中的其他部分将对这些模块进行更详细的描述。
核心模块在Node.js的源码 lib/ 文件夹中。
如果核心模块的模块标识传递给 require() ，则它们总是优先加载。 例如，即使有一个自定义模块叫 http ，我们去执行 require('http') 也将始终返回内置的 HTTP 模块，
当循环引用 require() 时，返回模块可能并没有执行完成。
考虑这种情况：
console.log('a starting');
exports.done =
const b = require('./b.js');
console.log('in a, b.done = %j', b.done);
exports.done =
console.log('a done');
console.log('b starting');
exports.done =
const a = require('./a.js');
console.log('in b, a.done = %j', a.done);
exports.done =
console.log('b done');
console.log('main starting');
const a = require('./a.js');
const b = require('./b.js');
console.log('in main, a.done = %j, b.done = %j', a.done, b.done);
当 app.js 加载 a.js 时， a.js 依次加载 b.js . 此时， b.js 尝试加载 a.js . 为了防止无限循环，将 a.js 导出对象的未完成副本返回到 b.js 模块。 b.js 然后完成加载，并将其导出对象提供给 a.js 模块。
当 app.js 加载了这两个模块时，它们都已经完成。 因此，该程序的输出将是：
$ node app.js
main starting
a starting
b starting
in b, a.done = false
in a, b.done = true
in main, a.done =true, b.done = true
模块包装器
在执行模块的代码之前，Node.js将使用一个函数包装器来将模块内容包裹起来，如下所示：
(function (exports, require, module, __filename, __dirname) {
// 你的模块代码
通过这样做，Node.js实现了以下几点：
它将模块内部的顶级变量(定义为 var ， const 或 let )的作用域范围限定为模块内部而不是全局。
它有助于给模块内部提供一些实际上只属于该模块的全局变量，例如：
module 和 exports 对象用来帮助从模块内部导出一些值
变量 __filename 和 __dirname 是当前模块最终解析出来的文件名和文件夹路径
module 对象签名
Object module {
id: String, // 模块标识，为该模块文件在系统中的绝对路径
exports: Object, // 该模块的导出对象
parent: Object | undefined, // 引用该模块的父模块
filename: String | null, // 最终解析的文件名称， 与__filename相同。
loaded: Boolean, // 该模块是否已经加载
children: Array, // 改模块的引用列表
paths: Array // 模块加载路径
require 函数签名
Function require {
[Function], // 函数体
resolve: Function, // 根据模块标识解析模块，返回绝对路径
main: undefined | Object, // 应用的主(main)模块
extensions: {'.js':Function, '.json':Function, '.node':Function},
cache: Object // 模块缓存，以模块的绝对路径为key
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具node最恶劣的设计，就是node_modules了 - CNode技术社区
积分: 2380
这家伙很懒，什么个性签名都没有留下。
一个项目，某个模块的副本可能超过10个，太浪费空间了：（
这个设计是有必要的， 不同的模块依赖的版本可能不相同。
java为何不这么干?应该向java学习的：（
你说反了，
node同时存在多个副本，也会导致混乱？
是个问题。
你因为模块多 服务器内存不够用了？
另外node的模块一般都不大，多个副本也占不不了多少空间，相对于减少依赖的复杂度来说，这点浪费应该是值得的。
“一个项目，某个模块的副本可能超过10个”
你这明显不会写package么
node_modules嵌套可能超过10层啊。。。。这不是浪费空间么？一个版本有一个副本不就够了么？
嵌套？ 是你自己不会写而已。
编程语言if else也能嵌套，但是会写的就不会多少嵌套。
node_modules 在规范上应该只有1层才对
你在模块里又放入node_modules文件夹，本身就是错误的。全局只应该有1个node_modules文件夹，所有的外部模块通过package管理。
你的系统应该类似这样放置:
-node_modules- a,b,c,...
// 任何第3方模块
//
你自己的代码
-src //
你自己的c代码
-... // 其他文件夹
node_modules/xxx/nodules_modules这种目录结构太常见了啊。。。
还有，如果你只是发布单个模块，文件里不应该带node_modules，而应该通过package.json指明你的依赖。
这样别人的node_modules文件里会自动加入依赖。
谁说这是常见的，这是严重的错误的。
这个反而是Node.js的优势……
加载模块还有缓存机制，所以性能上也不会因为模块多导致慢
Node.js 一个很不错的设计…在你眼里成了恶劣…目测应该是洁癖党…再说了…冗余点空间…比到时候各种版本冲突好不能太多了…
⊙﹏⊙b汗，A/B
A依赖B,B依赖C C依赖A
目录结构会是A/node_modules/B/node_modules/C/node_modules/A
显然通过.json指明依赖啊
跟你说了，这是错误的。
只要你的项目全局有一个node_modules，其他模块都会自动到这个文件夹中去挂载依赖。
而且这种方式，跟C语言的加载是很相似的。
同一个版本是否可能在内存中加载多份？
看一下这个
hexo\node_modules\gulp-jshint\node_modules\gulp-util\node_modules\chalk\node_modules\strip-ansi\node_modules
亮瞎狗眼了：（
小朋友总能写出神奇的代码，这有什么稀奇的。
错的不是语言，或者API，错的是使用者根本就不知道他使用的东西的机制。
上边的这个项目，明显是没有团队代码的概念。
应该肿么写？
-node_modules-
------------------------------gulp-jshint
------------------------------gulp-util
------------------------------chalk
------------------------------strip-ansi
------------------------------…
百科缺钱了。。。
如果是你 你会放过这个优化的机会么？
这样我看没啥问题。
汗，这得知道依赖关系才行啊。。。
任何在node_modules都会被全局引用到，依赖是很简单的
为何npm不自动把依赖下载到本地node_modules下，而是另外建立一个目录xxx/node_modules
那是因为你在下载的模块的文件夹中，直接install。
每次不用重复加载，有缓存吧
啥意思？不都是直接install的么？
我说的是加载到内存啊，亲：）
install之前要在项目package.json指明依赖，安装路径要在项目主文件夹install。
当然是在主目录install啊， 然后了那个很长的奇葩路径啊。。。
那你一个项目有多少模块啊。。。没有到内存受不了的程度吧
if (cachedModule) {
return cachedModule.
if (NativeModule.exists(filename)) {
// REPL is a special case, because it needs the real require.
if (filename == ‘repl’) {
var replModule = new Module(‘repl’);
replModule._compile(NativeModule.getSource(‘repl’), ‘repl.js’);
NativeModule._cache.repl = replM
return replModule.
debug('load native module ' + request);
return NativeModule.require(filename);
if (cachedModule) {
return cachedModule.
if (NativeModule.exists(filename)) {
// REPL is a special case, because it needs the real require.
if (filename == ‘repl’) {
var replModule = new Module(‘repl’);
replModule._compile(NativeModule.getSource(‘repl’), ‘repl.js’);
NativeModule._cache.repl = replM
return replModule.
debug('load native module ' + request);
return NativeModule.require(filename);
以路径来命名模块？
赶脚如果路径不同，模块有两个副本，也会当成两个模块，而不会有缓存功能。。
这个绝对是node.js的优势，这样做非常好，各个项目依赖的包版本号可能不相同，很好的独立各个项目，不像Python为了这个功能还需要搞一个 VirtualEnv 来管理各个项目的依赖包版本，node.js原生支持还不满足？
我不是韩国人
额是这样的，路径不同的两个一样的模块是不一样的
夸你棒。。。为什么会有这种先入为主的想法。。。为什么会首先想到韩国人，我都没说棒子
之前bower拉取bootstrap好像，想删除不让我删除，提示我超出文件长度啥的，嵌套好深，一层又一层…我win7系统…
用bower的好处是不需要把框架代码放在项目中?
这样版本库可以小一点？
没试过，不过应该可行，只要控制配置文件，自己install就可以了
感觉这个是node的优势，把依赖设计成树状而不是图状，能够很好的解决同一个模块的不同版本的依赖问题，这个浪费是非常值得的。
楼主,你确认你会用node_module? 一旦顶层有了这个module,下面就不再去下载了哦!
只能说 npm 和 node不是一起做的，npm的install -g 装到AppData\Roming\npm下面
node的require有全局路径
C:\user\Administrator.node_modules\ 但是npm 硬是自己搞一个
不爽npm可以自己搞一个出来吗，再搭个registry,就行了
其实楼主所说的情况很常见，并不奇怪。比如模块A依赖模块B，而模块B又依赖模块C，模块C又依赖模块D。然后在npm install的时候就会出现那样的文件目录，因为每个npm模块都应该有个package.json。
而安装的时候默认就是安装在其所在目录下。
但是楼主所担心的问题，nodejs在设计时候也已经考虑到了。
模块的加载机制，模块首次使用的时候，会缓存此模块编译好的文件。当require的时候首先是从缓存中获取，而缓存的模块其实是编译好的，这也大大减少了加载和编译的时间。其次才会去加载核心模块，自定义模块和文件路径模块。具体的加载机制你可以在google下
好消息…lz 的愿望在未来的npm 3.0 将会实现…
ps: 看来npm现在有钱,有时间,有人开发复杂功能了…
看到标题就知道LZ肯定会被教育。。。进来一看，果然~~
Try npm install npm
ls node_modules/npm/node_modules/request/node_modules
楼主需要的是dedupe命令
npm help dedupe
滚了一屏幕还是看到这个最振奋人心~~~~这问题是客观上普遍存在的，不过不是node的问题，算是npm的问题
不同嵌套深度的相同版本的模块会只被缓存一次？好像即使是两个相同版本的模块，还是会被当做完全独立的模块
这不是node的问题，你要是不嫌麻烦，把嵌套的node_modules里边的模块全部拷贝到根目录的node_modules里node运行也是没问题的。
楼主说的问题确实存在，windows用户应该经常碰到拷贝或者删除node_modules目录时系统报路径太长的错误，但那是npm的问题。
看了这么多其实我想问… 楼主是处女座的吧？
曾经因为目录路径太深，无法通过普通方式删除项目文件夹。
这么做的好处显而易见，a 依赖 b，c 依赖另一个版本的 b，两个版本的 b 差了一个大版本，不兼容。python 就很蛋疼，所有大环境只能用一套版本的包管理都很蛋疼。我是一个被 npm 宠坏的孩子，就是因为 node_modules。
npm dedupe 跑了半分多钟, 电脑都烫了
楼主可能不知道有个东西叫NODE_PATH环境变量。
此外，很多在全局安装过的包，在node_modules里是通过软链接的方式链接进去的。
这个时候跑过来挖坟是几个意思
npm3是模块就扁平化处理了，结果带来的麻烦是就是很难找对应的模块，依赖太多，一下子翻不过来.orz
CNode 社区为国内最专业的 Node.js 开源技术社区，致力于 Node.js 的技术研究。
服务器赞助商为
，存储赞助商为
，由提供应用性能服务。
新手搭建 Node.js 服务器，推荐使用无需备案的