在 YouTube 上观看了一些会议谈话后，我想我会尝试一下。
我在玩这个的时候遇到了这个问题： https://github.com/denoland/deno/issues/3793#issuecomment-578533918
Deno 的核心原则之一是 Deno 应该与浏览器兼容： https://youtu.be/z6JRlx5NC9E（11:55）
document目前，默认情况下，如果您使用诸如和之类的变量，tsconfig 将导致抛出错误window。
如果浏览器兼容是 Deno 的核心原则之一，那么它不应该"dom"在其默认的 tsconfig 中激活该库吗？
是的，对我来说很有意义。
这与我们所说的浏览器兼容性相反。Deno 没有document，它编译了它应该能够运行的东西。
也许你只是指用于 tsconfig deno bundle？请参阅https://github.com/denoland/deno/issues/3793#issuecomment-578550811。
这才是这个问题的根本原因。如果我运行，deno bundle我相信它应该能够捆绑基于浏览器的代码。
如果我Deno.bundle()在运行的文件中使用该 API，deno run那么默认情况下它也应该能够理解基于浏览器的代码。
作为一个临时修复，我发现将其附加到文件顶部是有效的（尽管 VSCode/non-deno-typescript 会引发错误）。
/// <reference lib="https://raw.githubusercontent.com/microsoft/TypeScript/master/lib/lib.dom.d.ts" />@ry，不，我宁愿交付#3726，并且只让这些适用于运行时编译器 API......允许其他库通过 Deno 本身不支持的库并对其进行类型检查会削弱 TypeScript 构建到 Deno 中的价值（在我看来）。
@kitsonk 你说得对，Deno 不应该接受它无法运行的代码。我收回我上面的“有道理”的评论。我想我们都同意，我们需要为用户创建一个没有错误的工作流程，让他们的同构应用程序中拥有 DOM API。
@PandawanFr 我确实认为这个解决方案非常酷......
好的，那么问题的答案是：
不，Deno 没有 DOM，因此默认情况下不应应用 DOM 库。
@Dan503，是的，但我们应该有办法以某种方式支持将其包括在内。正如#3726中提到的，我正在开始研究解决方案。
那么这是否意味着应该重新讨论这个问题？
不，因为我们不希望它默认处于开启状态。关闭 #3726 应该能够满足每个人的使用情况，并能长期支持。