Mobx DevTool's README指导您将其安装为dev依赖项，然后将其导入代码中。对我来说这似乎是个问题，因为this SO answer所解释的devDependencies是：
...用于构建过程，可为您提供帮助的工具 管理最终代码的最终方式，第三方测试模块，（例如 webpack的东西）
如果是这样，那您不应该将devDependency导入代码中是否正确？
答案 0 :(得分：2)
这取决于导入依赖项的代码的使用方式。如果仅在开发环境中使用它，则可以，它应该是devDependency，并且代码可以使用它。
如果使用它的代码将由包/模块/库的使用者使用，则它是直接依赖项，应这样注释。
这是一种查看使用依赖项的源文件的意图的方式。如果我使用npm install your-cool-package进行安装，则不需要，也不需要安装devDependencies，因为我可能不会从源代码，基准测试或测试中构建模块。我只是要食用它。
如果我需要依赖来使用您的模块，那么它就不是devDependencies，而只是一个直截了当的dependencies（或者也许是peerDependencies）。
问一下自己：当我使用您的模块时，要使其起作用，是否需要依赖项才能起作用？如果是这样，那就是依赖性。如果不是，那是开发人员的依赖。
如果您为某个东西创作一个插件，则取决于它所插入的东西。如果您编写了一个可以帮助人们开发事物的插件，则该插件仍然取决于插件所插入的内容，但是安装插件的人会认为您的插件属于开发依赖项，因为他们不需要开发时就不需要它。但是，您的插件仍然直接取决于它要插入的东西。
听起来您正在为模块（ Mobx ）编写插件（简称为 cool-plugin ）。我不使用 Mobx ，但这听起来像是一种开发工具。由于听起来酷插件需要 Mobx 才能执行任何操作，所以 Mobx 是的依赖项 cool-plugin ，但消费者会认为 cool-plugin 是他们假设的消费者模块的 devDependencies ，因为他们没有在生产中不需要它。
因此，您应该考虑 Mobx 为dependencies，因为没有它，模块就没有意义。
在某些情况下，您实际上应该将其视为peerDependencies，因为消费者模块可能不希望您安装自己的 Mobx版本< / strong>，但希望您与他们本应使用的接口进行交互。