手动符号链接(和Windows连接)

examples目录中不能包含一个node_modules，该node_modules带有指向项目根目录的符号链接吗?/因此允许示例使用require('project')，尽管这并没有删除映射，但它允许源代码使用require('project')而不是require('../../')。

我已经对此进行了测试，它确实适用于v0.6.18。

项目目录清单:

$ ls -lR project
project:
drwxr-xr-x 3 user user 4096 2012-06-02 03:51 examples
-rw-r--r-- 1 user user   49 2012-06-02 03:51 index.js

project/examples:
drwxr-xr-x 2 user user 4096 2012-06-02 03:50 node_modules
-rw-r--r-- 1 user user   20 2012-06-02 03:51 test.js

project/examples/node_modules:
lrwxrwxrwx 1 user user 6 2012-06-02 03:50 project -> ../../

index.js的内容将一个值赋给exports对象的一个属性，并调用console.log，并用一条消息声明它是必需的。test.js的内容是require('project')。

自动化的符号链接

手动创建符号链接的问题是，每次你npm ci时，你都会丢失符号链接。如果您使符号链接进程成为依赖项，那么就没有问题。

模块basetag是一个postinstall脚本，它在每次运行npm install或npm ci时创建一个名为$的符号链接(或Windows连接):

npm install --save basetag

node_modules/$ -> ..

这样，您就不需要对代码或require系统进行任何特殊修改。$成为您可以从中进行请求的根。

var foo = require('$/lib/foo.js');

如果你不喜欢使用$，而更喜欢#或其他(除了@，这是npm的一个特殊字符)，你可以fork它并进行更改。

注意:虽然Windows符号链接(到文件)需要管理员权限，但Windows连接(到目录)不需要管理员权限。这是一种安全、可靠、跨平台的解决方案。

我在我的项目中使用process.cwd()。例如:

var Foo = require(process.cwd() + '/common/foo.js');

值得注意的是，这将导致需要一个绝对路径，尽管我还没有在这方面遇到问题。

我也遇到了同样的问题，所以我编写了一个名为include的包。

包含通过定位包来确定项目根文件夹的句柄。Json文件，然后传递路径参数，你给它的本地require()没有所有的相对路径混乱。我认为这不是require()的替代品，而是需要处理非打包/非第三方文件或库的工具。类似的

var async = require('async'),
    foo   = include('lib/path/to/foo')

我希望这对你有用。

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

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

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

现在看一下这个片段:

global.appBasePath = __dirname;

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

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

如果你使用yarn而不是npm，你可以使用工作区。

假设我有一个文件夹服务，我希望更容易地需要:

.
├── app.js
├── node_modules
├── test
├── services
│   ├── foo
│   └── bar
└── package.json

要创建Yarn工作空间，需要创建一个包。services文件夹中的Json文件:

{
  "name": "myservices",
  "version": "1.0.0"
}

在你的主包里。json添加:

"private": true,
"workspaces": ["myservices"]

从项目的根目录运行yarn install。

然后，在代码的任何地方，你可以这样做:

const { myFunc } = require('myservices/foo')

而不是像这样:

const { myFunc } = require('../../../../../../services/foo')

在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.