大局

这看起来“真的很糟糕”，但要给它时间。事实上，它真的很好。显式的require()提供了完全的透明性和易于理解，就像项目生命周期中的一股新鲜空气。

可以这样想:你正在阅读一个例子，尝试Node.js，你认为它“在我看来真的很糟糕”。你在质疑Node.js社区的领导者，他们比任何人都花了更多的时间来编写和维护Node.js应用程序。作者犯这样一个新手错误的可能性有多大?(我同意，从我的Ruby和Python背景来看，乍一看这像是一场灾难。)

围绕Node.js有很多炒作和反炒作。但是当尘埃落定后，我们将承认显式模块和“本地优先”包是采用的主要驱动力。

一般情况

当然，首先搜索当前目录中的node_modules，然后是父目录、祖父目录、曾祖父目录等等。所以您已经安装的包已经以这种方式工作了。通常你可以从项目中的任何地方要求(“express”)，它工作得很好。

如果您发现自己正在从项目的根目录加载公共文件(可能是因为它们是公共实用程序函数)，那么这就是一个很大的线索，说明是时候创建包了。包非常简单:将文件移动到node_modules/，并放入package.json 在那里。瞧!整个项目都可以访问该名称空间中的所有内容。包是将代码放入全局名称空间的正确方法。

其他解决方法

我个人不使用这些技巧，但它们确实回答了你的问题，当然你比我更了解自己的情况。

您可以将$NODE_PATH设置为项目根目录。当您需要()时，将搜索该目录。

接下来，您可以折衷一下，从所有示例中要求一个通用的本地文件。该通用文件只是重新导出祖父目录中的真实文件。

Examples /downloads/app.js(以及其他类似的文件)

var express = require('./express')

/下载/ express.js例子

module.exports = require('../../')

现在当你重新定位这些文件时，最坏的情况是修复一个垫片模块。

如果有人正在寻找另一种方法来解决这个问题，这里是我自己的贡献:

https://www.npmjs.com/package/use-import

基本思路:在项目的根目录中创建一个JSON文件，将文件路径映射为简写名称(或者让use-automapper为您完成)。然后您可以使用这些名称请求您的文件/模块。像这样:

var use = require('use-import');
var MyClass = use('MyClass');

就是这样。

在Browserify手册中有一个非常有趣的章节:

avoiding ../../../../../../.. Not everything in an application properly belongs on the public npm and the overhead of setting up a private npm or git repo is still rather large in many cases. Here are some approaches for avoiding the ../../../../../../../ relative paths problem. node_modules People sometimes object to putting application-specific modules into node_modules because it is not obvious how to check in your internal modules without also checking in third-party modules from npm. The answer is quite simple! If you have a .gitignore file that ignores node_modules: node_modules You can just add an exception with ! for each of your internal application modules: node_modules/* !node_modules/foo !node_modules/bar Please note that you can't unignore a subdirectory, if the parent is already ignored. So instead of ignoring node_modules, you have to ignore every directory inside node_modules with the node_modules/* trick, and then you can add your exceptions. Now anywhere in your application you will be able to require('foo') or require('bar') without having a very large and fragile relative path. If you have a lot of modules and want to keep them more separate from the third-party modules installed by npm, you can just put them all under a directory in node_modules such as node_modules/app: node_modules/app/foo node_modules/app/bar Now you will be able to require('app/foo') or require('app/bar') from anywhere in your application. In your .gitignore, just add an exception for node_modules/app: node_modules/* !node_modules/app If your application had transforms configured in package.json, you'll need to create a separate package.json with its own transform field in your node_modules/foo or node_modules/app/foo component directory because transforms don't apply across module boundaries. This will make your modules more robust against configuration changes in your application and it will be easier to independently reuse the packages outside of your application. symlink Another handy trick if you are working on an application where you can make symlinks and don't need to support windows is to symlink a lib/ or app/ folder into node_modules. From the project root, do: ln -s ../lib node_modules/app and now from anywhere in your project you'll be able to require files in lib/ by doing require('app/foo.js') to get lib/foo.js. custom paths You might see some places talk about using the $NODE_PATH environment variable or opts.paths to add directories for node and browserify to look in to find modules. Unlike most other platforms, using a shell-style array of path directories with $NODE_PATH is not as favorable in node compared to making effective use of the node_modules directory. This is because your application is more tightly coupled to a runtime environment configuration so there are more moving parts and your application will only work when your environment is setup correctly. node and browserify both support but discourage the use of $NODE_PATH.

假设你的项目根目录是当前的工作目录，这应该是有效的:

// require built-in path module
path = require('path');

// require file relative to current working directory
config = require( path.resolve('.','config.js') );

大局

这看起来“真的很糟糕”，但要给它时间。事实上，它真的很好。显式的require()提供了完全的透明性和易于理解，就像项目生命周期中的一股新鲜空气。

可以这样想:你正在阅读一个例子，尝试Node.js，你认为它“在我看来真的很糟糕”。你在质疑Node.js社区的领导者，他们比任何人都花了更多的时间来编写和维护Node.js应用程序。作者犯这样一个新手错误的可能性有多大?(我同意，从我的Ruby和Python背景来看，乍一看这像是一场灾难。)

围绕Node.js有很多炒作和反炒作。但是当尘埃落定后，我们将承认显式模块和“本地优先”包是采用的主要驱动力。

一般情况

当然，首先搜索当前目录中的node_modules，然后是父目录、祖父目录、曾祖父目录等等。所以您已经安装的包已经以这种方式工作了。通常你可以从项目中的任何地方要求(“express”)，它工作得很好。

如果您发现自己正在从项目的根目录加载公共文件(可能是因为它们是公共实用程序函数)，那么这就是一个很大的线索，说明是时候创建包了。包非常简单:将文件移动到node_modules/，并放入package.json 在那里。瞧!整个项目都可以访问该名称空间中的所有内容。包是将代码放入全局名称空间的正确方法。

其他解决方法

我个人不使用这些技巧，但它们确实回答了你的问题，当然你比我更了解自己的情况。

您可以将$NODE_PATH设置为项目根目录。当您需要()时，将搜索该目录。

接下来，您可以折衷一下，从所有示例中要求一个通用的本地文件。该通用文件只是重新导出祖父目录中的真实文件。

Examples /downloads/app.js(以及其他类似的文件)

var express = require('./express')

/下载/ express.js例子

module.exports = require('../../')

现在当你重新定位这些文件时，最坏的情况是修复一个垫片模块。

在简单的行中，你可以调用自己的文件夹为module:

为此，我们需要:global和app-module-path module

这里“App-module-path”是模块，它允许你添加额外的目录到Node.js模块搜索路径 global的意思是，你附加到这个对象的任何东西b在你的应用中都是可用的。

现在看一下这个片段:

global.appBasePath = __dirname;

require('app-module-path').addPath(appBasePath);

__dirname为节点当前运行目录。您可以在这里给出自己的路径来搜索模块的路径。