【问题标题】:What dependency type should @types be for a published package?对于已发布的包,@types 应该是什么依赖类型?
【发布时间】:2019-07-22 09:48:10
【问题描述】:

我正在创建一个打算发布到 NPM 的包。我正在用 typescript 编写包,并设置了我的 tsconfig 文件以发出 typescript 声明文件以及已编译的 javascript,因此使用 typescript 的其他人可以在他们的 IDE 中获得正确的类型信息 - 非常标准。我正在使用一些肯定类型的包,但不确定它们应该是什么依赖类型。如果有人在 typescript 项目中使用我的包,我的声明文件将需要安装相关的 @types 包,但如果他们使用的是 javascript,则不需要安装这些包。我在想 @types 包应该在我包的 package.json 文件的 optionalDependencies 中。这是正确的吗?

【问题讨论】:

    标签: typescript npm definitelytyped


    【解决方案1】:

    According to Brian Terlson,应该使用远程对等依赖项作为经验法则。

    正常依赖(不推荐)

    您选择@types 的版本,但不能保证它与您的消费者使用的版本相匹配。例如,当您的用户在节点 11 上时,您可能会选择 @types/node@10.0.0。

    开发依赖(不推荐)

    因为当你的消费者安装你的包时它们并没有安装,所以他们需要自己将它添加到他们的项目中(假设他们使用的是 TypeScript)。

    在您的源代码中镜像开发依赖项(有时推荐)

    如果您对@types/* 的使用很少,那么在您的代码中镜像使用的类型定义可能是有意义的。模仿第三方定义正在做的事情并将其保存在您的代码中。缺点是必须让您自己的定义与其原始版本保持同步。

    对等依赖(推荐)

    中间立场。它们将被你的包和你的消费者的包安装和重用。唯一想到的问题是多个库依赖于某些@types/*,但它们的版本不匹配。

    【讨论】:

    • 感谢您的信息!看起来 Peer Dependency 可能是最好的选择,如果它与他们相关,用户可以选择安装 @types 包
    猜你喜欢
    • 2021-10-15
    • 1970-01-01
    • 2012-03-09
    • 2018-07-20
    • 2018-07-29
    • 2021-07-04
    • 1970-01-01
    • 2021-02-21
    • 2017-04-14
    相关资源
    最近更新 更多