【问题标题】:Best practice in organizing NPM module exports in a typescript library project?在打字稿库项目中组织 NPM 模块导出的最佳实践?
【发布时间】:2020-12-04 19:56:44
【问题描述】:

我正在使用 Typescript 编写一个库包,以发布到 npm 注册表,以便其他各种项目可以使用它。

我已按照publishing doc 确保--declaration 选项对于tsc 是正确的,以便在*.d.ts 文件中也导出类型定义。

我现在的问题是,这些导出分散在各个文件夹中,我的包的消费者正在像下面这样导入它们。

import { FooType } from 'my-test-pacakge/dist/src/foo/types';
import { BarInterface } from 'my-test-package/dist/src/foo/bar';

我想知道这是否可以接受,因为它看起来很乱。我应该编写自己的声明文件以更简洁地组织它们吗?

已有类似问题的答案建议exporting the API through a general index.ts file。这对我来说听起来很合理,但我只是想知道直接从 dist 文件夹导入是否被认为是不好的做法?

【问题讨论】:

    标签: typescript npm


    【解决方案1】:

    大多数包更喜欢从 1 个导出点导出,这样您的库的用户就不需要知道任何关于您包的目录结构的信息。

    import { FooType, BarInterface } from 'my-test-package'.
    

    一个额外的好处是,您可以在不影响最终用户的情况下重新构建包的内部结构,并且它清楚地描述了您打算由包的用户使用哪些项目,以及哪些项目是包的内部.

    所以是的,我同意这是最佳做法。

    有些包有额外的命名空间,我想到了mysql2 包,它有两个主要的导出:

    import { Connection } from 'mysql2';
    import { Connection } from 'mysql2/promise';
    

    但请注意,这里没有像 dist 这样的东西。 dist 对最终用户没有意义。

    【讨论】:

    • 非常感谢!这无疑强化了我这样做的想法。我还遇到了这个博客,它以非常简洁的方式谈论了相同的主题。 betterstack.dev/blog/…
    猜你喜欢
    • 2010-10-19
    • 2016-10-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-11-15
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多