当前位置: 首页 > 知识库问答 >
问题:

是否有任何充分的理由在打字稿项目中将编译器选项“声明”设置为 true

祁晟
2023-03-14

我有一个打字稿项目,将来我可能想将其发布为 NPM 包。

现在,我已经在我的< code>tsconfig.json中设置了< code >“declaration”:true 。然而,这给我带来了一些问题(对这个问题来说并不重要)。

如果我将其设置为false,一切都按我希望的那样工作。

< code>declarathtml" target="_blank">ion标志设置为true时,会生成< code>d.ts文件。然而,根据我对typescript中“*.d.ts”的理解,这只有在您还没有使用typescript编程的情况下才有意义(即您的项目是javascript),这样您以后就可以在TypeScript项目中轻松地使用这个javascript库,因为您现在已经有了类型。

那么,当项目是“纯”打字稿时,为什么有人要将此设置设置为true呢?我可以安全地将其设置为false吗?

共有1个答案

马银龙
2023-03-14

在打字稿项目中,是否有充分的理由将编译器选项“声明”设置为true?

特别是如果您要作为 NPM 包发布!

创建NPM包时,应包含。js.d.ts文件,而不是。ts文件。这使您的包真正具有可移植性,并确保TypeScript项目和普通的旧JavaScript项目都可以使用它。

这是 NPM 上 TypeScript 的推荐打包机制,有关发布的更多信息可以在手册中找到。

 类似资料:
  • 问题内容: 我正在使用Go(6g)编译GTK应用程序,我想知道是否有编译器/链接器选项,使其成为Windows可执行文件,而不是控制台可执行文件。MinGW为此提供了- mwindows选项,当前我不得不使用令人讨厌的十六进制编辑器手动更改PE标头。 问题答案: “标志列表”参数在每个5l,6l或8l链接器调用上传递 编译软件包和依赖项 (仅在6l / 8l中)编写Windows PE32 + G

  • 我已经阅读了一段时间关于Maven中显式和传递(隐式)依赖声明的内容。大多数人倾向于同意,您应该始终显式声明项目所依赖的库,主要是为了避免版本不匹配。 这是完全合理的,但我们应该如何处理我们的内部依赖?我认为绝对没有理由保持模块之间的显式依赖关系,如果它们可以通过传递机制解决的话。 我的用例场景: 我的团队在发布周期,例如:1.1.1、1.1.2、1.3.0等 我的直觉告诉我——摆脱对意大利面条的

  • 我正在使用ScalaPB(版本0.11.1)和插件sbt-pro c(版本1.0.3)尝试在Scala 2.12中使用SchemcolBuffers编译一个旧项目。阅读留档,我想将文件属性设置为。但我的问题是,在哪里?我需要在哪里设置这个标志?在. proto文件上? 我还尝试通过创建包将标志作为包范围的选项。我的另一个旁边的原型文件。原型文件,具有以下内容(如此处所述): 但在尝试编译时,我得到

  • 我正在处理打字稿,并将一个函数传递给另一个函数。 如果我有一个传递到typescript中另一个函数的函数,我应该如何编写类型? 我尝试了,但似乎不起作用。

  • 前面我们讲了编译项目是对新产生变化的文件进行一次编译,已经编译过的文件就不用重编译了. 所以如果你想加快编译速度,可以设置项目自动编译. 操作步骤: Android Studio --> Preferences... --> 搜索Compiler --> 勾选Make project automatically

  • 问题内容: 我们都知道,将字符串传递给(或)是邪恶的,因为它是在全局范围内运行的,存在性能问题,如果您注入任何参数等,则可能不安全。因此,绝对不建议这样做: 赞成: 我的问题是:有没有理由做前者?有 没有 更好的选择?如果不是,为什么甚至允许呢? 我想到的唯一一种情况是希望使用全局范围内存在但局部范围已被覆盖的函数或变量。在我看来,这听起来像是糟糕的代码设计,但是… 问题答案: 您始终可以通过将全