Question

典型的TypeScript模块包含带有TypeScript源代码文件的src目录，运行tsc -d --outDir dist以将源编译为dist，并设置以下程序包元数据以使两个Node.js运行时和TypeScript编译器了解模块要导出的内容：

{
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "files": ["dist"]
}

为了使调试更容易，通常还需要软件包附带源地图和原始源代码。

借助最近推出的Project References和编译器选项--declarationMap，我认为模块也应该提供声明映射文件，以允许IDE从调用模块API的位置直接跳转到实现，而不是跳转到生成了.d.ts个文件。

因此，一个模块将打包以下文件：

已编译的.js文件
原始.ts文件

.d.ts

声明

.d.ts.map

声明映射

对我来说，此设置似乎过于复杂，并提出一个问题-如果我们摆脱了.d.ts和.d.ts.map文件，而代之以原始TypeScript源代码呢？

{
  "main": "dist/index.js",
  "types": "src/index.ts",
  "files": ["src", "dist"]
}

我想到的几个缺点：

根据我的模块编译项目时，TypeScript编译器将有更多工作要做。代替解析密集的.d.ts文件，它必须解析完整的.ts源。因此，构建速度可能会变慢。
类似于VSCode这样的IDE：语言服务必须解析完整的.d.ts.map源，而不是加载最可能为快速解析而优化的.ts文件。

.d.ts和.ts文件之间也有细微的差别。前者仅导出声明（例如declare class Foo {}），而后者则导出定义（例如class Foo {}）。我对TypeScript处理依赖树中存在同一模块的多个实例的情况的方式并不完全熟悉。它将声明的多个副本与定义的多个副本区别对待吗？

是否还有其他反对将原始.ts文件用作类型声明的论点？

Answer 1

通常需要软件包附带源地图和原始地图源代码。

部分正确。源映射确实已包含您的源代码。这就是为什么如果只有源映射的话，DevTools能够从缩小的JavaScript代码重新创建原始源的原因。

我可以看到的一个缺点是包裹的大小。声明文件是轻量级的。大多数库可能用一个少于100行代码的声明文件来描述。

但是，小的API界面并不意味着没有太多的源代码。您可能有一个包含数千个模块的项目，但是其公共API是一个接口。使用*.d.ts文件来描述它可以使您的使用者在他们的机器上节省大量空间。

导出原始.ts文件而不是.d.ts文件作为模块类型声明的后果

1 个答案: