本文主要介绍使用的风险以及为什么我们使用它来替换它。
使用或使用软来连接本地软件包作为依赖项而不是使用
NPM链接是Hiroki Osame开发的更安全，更可预测的替代方案。
由于以下原因，我们应该避免使用它
这是一条命令行，在开发时将本地软件包直接链接为依赖项。通常用于在发布NPM软件包之前使用本地测试
有关更多信息，请查看正式文档
假设以下模块包
应该注意的是，这里的属性也应
以下说明了如何将链接放在当地
执行将安装到全球。这样，其他本地项目可以链接到此软件包。行为实际上与
在中间执行此软件包
您也可以直接执行命令以实现上述两个步骤
示例如下：
它更方便，不容易犯错，因为它是需要明确指定的路径。
如果您使用类似版本的管理工具在开发环境中安装多个node.js版本，则需要确保执行在相同的节点版本中
如上所述，第一步是整体安装软件包。
您可以使用以下命令查看全局软件包的安装路径。如果Node.js的版本出现在打印路径中，则全局软件包安装路径在不同的Node.js版本下是独立的
在处理不同终端中的多个软件包时，很难忽略Node.js版本是否一致，并且很难找到此版本的差异，因为当您找不到无法找到本地软件包链接时，它不会报告错误。
如果您尝试在软件包中执行执行，即使此包没有注册为全局链接，此命令执行也不会报告错误
这是因为当没有全局软件包时，它将从仓库安装此软件包，并创建到该软件包的软链接。
只有此软件包在NPM的远程仓库上没有此软件包
为了确定链接是否真的成功，您可以检查输出的两个打印件。请注意上面只有一个错误链接。两个描述创建了一个指向全局软件包软链接，然后链接到本地软件包
此检查方法只能在NPM V6版本中使用。从NPM V7启动，链接路径不再输出到终端。从以下内容，可以发现V7不能再确定是否确定是否链接链接的本地软件包成功或安装了包裹并链接
您还可以使用命令来验证软件包是否成功
总而言之，由于缺乏适当的错误，我们的使用不是一个好体验。尤其是在多个node.js版本的情况下
第一步是将软件包安装到整体情况下。此命令通过两个步骤实现
npm install -global ...它可用于将二进制文件用作系统范围内的CLI命令。如果有一个字段，您可以通过终端直接通过终端执行命令。
考虑到通常用于开发中测试，全局二进制文件的安装可能具有其他副作用。
以下示例在中间指定
执行也将安装全局
全局安装还将涵盖现有的全局执行命令（取决于配置末端搜索命令的环境变量）。如果您使用NVM，则可能会受到影响
以下示例涵盖了标准UNIX命令
在包装安装方面，这些风险对于包装管理非常普遍。从安全的角度来看，这些风险不是太高
但这不是包装安装工具。它是开发过程中软链接的工具。通过上述情况，我们了解这种行为将导致许多预期的行为和一些可能导致的错误
顺便说一下，上述操作，已在系统中安装了二进制执行命令。它可以被认为是卸载的，但它只会删除本地软链接而不会删除全球安装的二进制文件
卸载全局软件包及其二进制执行文件需要使用：
链接多个软件包时，您将删除上一个链接。此行为是在NPM V7中引入的
以下示例一直在链接并存在。但是当链接在第二个软件包中时，它消失了
当使用多个软件包用于链接时，删除先前的链接软件包通常不符合期望。在链接的第二个软件包之后，我们将继续运行代码，并认为以前的软链接应保持不变。
如果要链接多个软件包，则必须一次通过所有路径步道
虽然可行，但这不是一个很好的发展经验。在发展中，我们并不总是知道所有需要提前链接的行李或以前链接的袋子
这种令人困惑的行为说明了可用性不佳
与任何发布一样，NPM都有多样化的收藏，没有任何疑问的标准。
作为一种流行的行李管理工具，NPM有多种包，但没有统一的质量标准
这里列出了一些恶意软件包，但是此处提到的风险不仅限于攻击。在安装正确的软件包时可能会发生。
NPM上的许多软件包都用于更改文件，例如RIMRAF或代码Linter工具。可能在运行文件中更改的代码可能是可能的
也可以安装错误的软件包，但是当您了解上面提到的一些预期行为时，风险将更高。如下：
另一种方法是使用指定的软件包路径
执行此命令将在软件包中创建一个软链接，而不是全局安装。此行为几乎与我们的测试包的原始意图相同。
但是有缺点。好像在上一个软链接之前将删除执行，如果我们想一次链接多个袋子，我们必须传递多个需要链接为参数的软件包
一个小工具用于替换并可以解决上面提到的缺点
很容易使用
将不会在全球安装的软件包或二进制执行文件，并且将不会删除先前的软链接，这些链接可以在不同版本的node.js.js中使用，当时数据包路径无法解析，也将在其中使用
如果您需要执行链接软件包的二进制文件，请执行命令或通过软件包脚本
原始：https：//hirok.io/posts/avoid-npm-link