我正在用NodeJS编写一个供其他人使用的库。该库具有依赖于测试框架的测试，因此该框架在devDependencies的{{1}}部分中列出，因此将我的库加入其代码的任何人都不会下载我的测试框架，然后将其忽略
但是，我还有一个到库的命令行界面，如果有人选择全局安装库，则应该安装该命令行界面，但是当其他人将库拉入自己的项目时，也应该忽略该界面。此CLI有一些依赖关系，因此我试图找出在哪里列出它们，以便在全局安装（或在库本身的开发工作期间）时将它们引入，而在另一个项目将库作为依赖关系引入时将其忽略。 / p>
如果我在主package.json部分中列出了CLI依赖项，那么该库的用户将把它们全部拉入自己的代码中，即使他们从不使用CLI，因此绝对可以错误的地方。
如果我将它们列为dependencies，那么它们将被排除在其他项目之外，这是理想的选择，但是，如果有人尝试使用devDependencies全局安装该库，则CLI依赖项将是省略，并且CLI将不起作用，即使在这种情况下，“生产”安装肯定应该包括CLI。
--production看起来并不像我想要的那样，因为我不想在任何捆绑软件中包括CLI依赖项，因为最有可能的情况是CLI不会被使用。
bundledDependencies在这种情况下似乎不相关。
peerDependencies似乎并不理想，因为如果CLI依赖项由于某种原因而失败，则将继续进行全局安装，但CLI将无法工作，这是在全局上进行安装的关键。
将CLI移到单独的程序包中也是一种选择，但是CLI在库开发过程中至关重要，因此将它作为单独的程序包的一部分会使开发工作变得更加困难，所以我想这样做避免。
看来optionalDependencies是唯一的选择，但是由于它有一些局限性，因此我想确认在进行此操作之前确实没有更好的选择！
答案 0 :(得分：1)
我认为最好的方法是将CLI放在单独的程序包中，类似于express-generator，这是用于快递的CLI。
即使对于开发至关重要，您的库用户也只需键入一个额外的命令npm install library-cli，并且如果对此进行了正确记录，我看不到任何问题。
您还可以在安装软件包后将postinstall脚本或自定义脚本添加到安装CLI的主库中：
"scripts": {
"postinstall": "npm install -g library-cli"
}
但是，如果您选择将CLI与主库捆绑在一起也可以，但是在这种情况下，您不应将CLI依赖项放入devDependencies中。即使90％的用户永远不会使用它们，运行cli所需的所有模块也都应该放入dependencies中。
devDependencies应该用于构建过程中所需的所有工具，例如缩小，测试，打字稿等。CLI在运行时所需的所有内容 dependencies。