用于定义外部可配置选项的打字稿习语

Question

人们使用什么习惯用法来定义 Typescript 中的配置选项，以便其他模块可以使用选项类型定义？

我来自 Java 背景，我要做的显而易见的事情——在默认导出上放置一个内部类型——由于a bug in Typescript 还没有工作：

export default class MyClass {

    constructor(opts: Options) {
        //...
    }
}

namespace MyClass {
    export interface Options {
        //...
    }
}

相反，我似乎必须将 MyClass 和 Options 作为模块的兄弟姐妹导出，或者将它们作为默认值导出到单独的模块中。

这些解决方案中的第一个要求我在命名只有一个类的模块时具有额外的创造力，因为除了类之外，该模块还公开了一个接口。

第二种解决方案会产生大量额外的模块/文件，特别是因为这是 Javascript 程序员习惯于配置所有内容的方式。

想到的唯一合理的解决方案如下：

• 将类和选项接口导出为同一模块的同级。
• 为该类命名该模块（例如myclass）。
• 在其他地方，import { MyClass, Options as MyClassOptions } from 'myclass'。

也可能是 Typescript 的方式是从单个模块中导出大量类，并为调用者的命名空间唯一地命名每个类。在这种情况下，也许人们正在做类似import { MyClass, MyClassOptions } from 'bigmodule' 的事情。实用，但并不理想。

谷歌搜索并没有让我深入了解人们实际在做什么。那么常见的成语有哪些呢？我是否完全偏离了如何在 Typescript 世界中使用选项配置？其他一些配置模型是否更普遍？放弃命名选项类型？

更新#1：为什么重要？因为我正在制作一个在 NPM 上发布的框架，希望其他人会发现配置问题很熟悉。

更新 #2：我了解到上述方法接近于可行的方法，并且更易于重构。该模块会这样做：

export class MyClass { // no default

    constructor(opts: Options) {
        //...
    }
}

export namespace MyClass { // with export
    export interface Options {
        //...
    }
}

并且客户端可以干净简单的导入如下：

import { MyClass } from 'mymodule';

function getOptions(): MyClass.Options {
    //...
}
let obj = new MyClass(getOptions());

但我仍然不知道可能会发生什么约定。我会在学习各种框架时报告回来，除非有人能打败我。

Answer 1

模块不等于单个类，它是一组紧密相关的行为。

考虑到这一点，我会推荐您现有的建议：

export class MyClass {
    constructor(opts: Options) {
        //...
    }
}

export interface Options {
    //...
}

命名

还有一个技巧来命名诸如你的模块之类的东西。写一张“同类事物”的快速表格，然后根据您对这些事物的称呼来命名您的模块。

例如，如果你的班级被称为“Crisps”，你会扩展它：

1. 薯片
2. 坚果
3. 猪肉抓痕

然后你可以将你的模块命名为“Snacks”。

大模块

如果您注意将因相同原因更改的代码放在一起，并在出于不同原因更改时将其分开，您不应该发现自己使用大模块。