如果你想进一步自动化这个，因为你正在将你的模块检入版本控制，并且不想依赖于开发人员记住npm link，你可以将这个添加到你的包中。Json“脚本”部分:

"scripts": {
    "postinstall": "npm link ../somelocallib",
    "postupdate": "npm link ../somelocallib"
  }

这感觉很俗气，但似乎很“管用”。从这个npm问题中得到了提示: https://github.com/npm/npm/issues/1558#issuecomment-12444454

使用工作空间

使用该文件的缺点:../path/to/your-library是你必须安装NPM或使用NPM link，以使更改在导入你的包的包中生效。

如果你使用pnpm:一个更好的解决方案是使用workspace: protocol: workspace:../path/to/your-library。它会将目录符号链接到您的node_modules目录，而不是复制它，因此源上的任何更改都会立即生效。

例如:

  ...
  "dependencies": {
    ...
    "my-package": "workspace:../../dist"
  },

注意:此解决方案打算在工作空间中使用，因此可能需要创建pnpm-workspace。Yaml(甚至是一个空文件)文件在您的项目的根。

在2020年的这里，我正在用Windows 10操作系统工作

"dependencies": {
    "some-local-lib": "file:../../folderY/some-local-lib" 
    ...
}

然后进行npm安装。结果是在节点模块中创建文件夹的快捷方式。 这行不通。你需要一个硬链接-哪个窗口支持，但是 你必须在Windows中做一些额外的事情来创建一个硬符号链接。

因为我不是真的想要一个硬链接，我尝试使用一个url代替:

"dependencies": {
    "some-local-lib": "file:///D:\\folderX\\folderY\\some-local-lib.tar" 
     ....
}

这个很好用。 tar(你必须tar库的build / dist文件夹中的东西)被提取到node-modules中的一个真正的文件夹中，你可以像其他东西一样导入。 显然tar部分有点烦人，但由于'some-local-lib'是一个库(无论如何都要构建)，我更喜欢这个解决方案，而不是创建一个硬链接或安装一个本地npm。

完整的纱线用户本地开发指南:

首先在主项目中添加依赖项:

cd main-project
yarn add file:../path/to/your-library

接下来，如果你想避免在每次改变它的源代码时重新构建这个依赖:

cd your-library
yarn link

这将注册一个到你的库的链接。接下来，使用刚刚在主项目中创建的链接。

cd main-project
yarn link your-library

现在，每次更改库中的代码时，您都不需要重新构建它，它将自动包含在主项目中。Yarn link的工作原理是在你的node_modules文件夹中创建符号链接，在这里阅读更多信息:https://classic.yarnpkg.com/lang/en/docs/cli/link/

用纱线可以这样做

纱线添加文件:../somelocallib

现在可以在包中指定本地Node模块安装路径。直接json。从文档中可以看出:

Local Paths As of version 2.0.0 you can provide a path to a local directory that contains a package. Local paths can be saved using npm install -S or npm install --save, using any of these forms: ../foo/bar ~/foo/bar ./foo/bar /foo/bar in which case they will be normalized to a relative path and added to your package.json. For example: { "name": "baz", "dependencies": { "bar": "file:../foo/bar" } } This feature is helpful for local offline development and creating tests that require npm installing where you don't want to hit an external server, but should not be used when publishing packages to the public registry.