1. 首页
  2. 问答
  3. [denoland/deno]deno 包不支持 tsconfig.json

[denoland/deno]deno 包不支持 tsconfig.json

2024-07-17 349 views
4
// bundle.ts

// @ts-ignore
import { hello } from './hello.ts'
// @ts-ignore
import { button } from './button.ts'

document.addEventListener('DOMContentLoaded', () => {
    hello()
    button()
})
deno bundle bundle.ts bundle.js
error TS2584: Cannot find name 'document'. Do you need to change your target library? Try changing the `lib` compiler option to include 'dom'.

因此我tsconfig.json在项目的根目录中添加了一个：

{
    "compilerOptions": {
        "strict": true,
        "lib": ["ES2019", "dom"]
    }
}

我仍然收到同样的错误：

error TS2584: Cannot find name 'document'. Do you need to change your target library? Try changing the `lib` compiler option to include 'dom'.

我去寻找答案，并根据这个合并的拉取请求，看起来我需要添加--config tsconfig.json到命令中。

deno bundle bundle.ts bundle.js --config tsconfig.json
error: Found argument '--config' which wasn't expected, or isn't valid in this context

Deno 版本：0.31.0

Dan503

回答

1

我在尝试使用装饰器捆绑文件时也遇到了这个问题。CLI 标志已在 #3365 中清理，因此我不确定删除config捆绑是否是疏忽。

artisonian

8

为什么不呢？对于想要通过运行来创建基于浏览器的 JS 代码的捆绑版本的人来说，这似乎是相当合理的deno bundle。

Dan503

2

请参阅 #3726。这将允许人们轻松创建一个充当浏览器代码编译器的用户模块。不应明确内置此功能。一个与前端代码有关而其他子命令无关的笨拙子命令是不合理的。

nayeemrmn

7

或许可以这样想。

Web 开发社区有 browserify、rollup 和 webpack。所有这些本质上都是用于捆绑前端代码的 JS 代码捆绑器。

现在 Deno 出现了，他说：“嘿，大家看！我们已经将代码捆绑直接内置到系统中。无需插件！”

每个人都开始尝试使用 Deno 来打包他们的前端 JavaScript，就像他们在 Deno 之前使用过的其他代码打包器一样。然后，当 Deno 说它不理解浏览器代码时，每个人都很快遇到了障碍。

你知道这会让人们感到困惑和烦恼吗？

Dan503

7

@Dan503 如果我确实随机假设这个运行时上的 bundle 命令意味着为其他运行时进行捆绑，那么我肯定会对自己感到恼火。

但是是否要有这个功能的问题从这里开始讨论https://github.com/denoland/deno/issues/2475#issuecomment-526993668。它的要点是，“好的”捆绑器可以做的比这里给出的要多得多。将它构建到试图最小化的服务器运行时中没有任何意义。有一个没有问题import。

nayeemrmn

0

即便如此，我的问题是无法启用实验性装饰器，如果你想分发一个包而不需要别人添加的话，这仍然有效tsconfig.json。

artisonian

7

它应该支持tsconfig.json，但就像deno run它总是会忽略lib库一样。

对于浏览器的捆绑，您需要使用Deno.bundle()正在交付的#3726。

kitsonk

2

我认为@Dan503 是正确的，他描述的案例场景发生在我身上。

@nayeemrmn

我从未想过 Deno 只会捆绑自己的运行时，也许这很幼稚，但我相信我不是唯一一个这么想的人。当你说“其他运行时”时，主流实际上只有 deno、node 和浏览器。Node 可以被视为遗留的，因此只剩下两个运行时。

我想请 Deno 开发人员考虑一下，JS/TS 的绝大部分用途实际上是前端浏览器代码。后端编程只是少数人的兴趣。大多数人安装并使用 Node 来运行构建工具并访问 NPM。Deno 是一个绝佳的机会，可以打破这种古老而繁琐的做法，为整个 JS/TS 社区开创一个简单易用的新时代。

默认 ES 模块和摆脱 NPM 是一场让所有人受益的革命，而不仅仅是后端程序员。

我真的希望 Deno 能发展成为所有 JS/TS 开发人员的一站式商店。一个命令行程序可以为浏览器和它自己编译、测试、检查和格式化代码。它几乎已经可以做到这一点了。我明白这可能是开发人员的一个次要目标，但应该认真考虑帮助这么多人并推动事情向前发展的机会。

无论浏览器兼容性是在标准库中完成还是内置，只要它开箱即用并且得到完全支持，那就没什么区别。

https://github.com/denoland/deno/issues/3726看起来很棒，但请确保使用标准库可以立即使用其功能。可以在此处包含新的浏览器捆绑程序，稍后可以添加 tree shake 等。

David-Else

2

我觉得有几点...

将“浏览器”视为单一运行时是愚蠢的。虽然常青浏览器正在迅速采用大多数功能，但仍然存在相当多的差距。一旦您添加需要针对移动浏览器和 IE11（许多企业环境的现实情况），您现在仍然面临一个非常不平衡的局面。它远非单一运行时。Web 平台很复杂，远不止符合 ECMAScript。它包含大量的 API 以及大量的其他技术（CSS、HTML、SVG、WebGL、WASM、WASI 等）。

Node.js 被“遗留”在这一点上也是一种愚蠢的行为。即使 Deno 非常成功，并“取代”了 Node.js，这也会是一条漫长的道路。忽视它以及它继续发展的能力也是愚蠢的。

我认为大多数开发都是 JavaScript 的“前端”这一观点与个人所处的位置有关。我个人的经验是后端有大量的 JavaScript。我认为非前端开发根本不是少数人的兴趣。

我和 @ry 昨天大致聊了聊这个问题，我认为谈话的结果是：

  • deno bundle就像deno run是为了让在 Deno 中运行的开发工作负载更容易/更好/等等。他们固执己见，并且永远如此。他们是“后备箱”。仅仅因为某些deno fetch输出可以导入浏览器是一种副作用，而不是最终用户应该耦合的东西。deno testdeno bundle
  • 以低摩擦、低配置的方式构建 Web 应用程序的工作流程是 Deno 的一个很好的用例，并且应该“正常工作”。但这应该采取可选的形式，并且是标准库的一部分……所以类似于deno https://deno.land/std/build/react.ts ./index.ts，输出将考虑到它将在浏览器中运行（而不是在 Deno 下，因此没有Deno命名空间），以及执行获得有效包所需的其他操作。
3726 是该解决方案的一部分，但我还将致力于添加一些内容，作为std构建更强大解决方案的起点，社区可以帮助适应前端开发工作流程。

kitsonk

0

我一直都是这么想的deno bundle。

是的，需要一个面向浏览器的捆绑包，但是所有这些功能的工作量应该作为辅助工具，而不是项目的主要目标。

Deno 提供了一组 Node 所缺乏或模糊对待的工具，这些工具在很多情况下都由支持 Node 的社区解决，例如 Webpack、Prettier、ESLint（也许没有那么多）以及使 BackEnd 开发变得不那么麻烦。然而，这使得 Node 更像是一个空壳，因为如果您只安装了 node 并开始使用它进行编程，那么必备的功能就无法实现。这导致人们混淆核心功能和为扩大其在 Node 环境中的覆盖范围而制作的插件。

Deno 的主要功能是类似于 Rust，弥补 JS 原生在后端领域的不足（Deno 工具集的很多理念都是基于 Cargo，至少看起来如此）。

因此，即使 Deno 支持 JSX，你也不会指望它集成了 React，对吧？或者在代码中嵌入了与 Node 的兼容模块。

那将是额外的，因为它们超出了项目的范围，并且它们本身是一套需要不断维护的大型工具。

多年来，Webpack 和 Babel polyfill 一直在不断发展和改进，因为遗留和不明确的 JS 版本系统是一个非常微妙的问题，所以我非常希望它们与主要的 Deno 核心分开。

Soremwar

4

我觉得编译需要目标架构是有道理的。arch 类型对应不同的变压器。

这样，就可以在用户空间创建变压器并将其添加到 deno。

说

deno bundle --arch=browser --type=esm
deno bundle --arch=browser --type=umd
deno bundle --arch=deno
deno bundle --arch=wasm

但它考虑了 tsconfig.json

顺便提一下，请解决发出的 js 和 d.ts 文件中的路径转换问题。天哪，用绝对路径编写 TS 库是不可能的。

alshdavid

0

@alshdavid 这种灵活性正是Deno.bundle()API 的用途所在。

kitsonk

5

我看到了合并。不过看起来你仍然需要写这个：

deno bundle bundle.ts --config tsconfig.json

为了使用 tsconfig.json 进行编译，您只需写下以下内容：（并在根文件夹中有 tsconfig.json）

deno bundle bundle.ts

Dan503

4

@Dan503 我们总是明确说明 Deno 中的事情。我们不会自动解析tsconfig.json（或任何其他外部文件）。

kitsonk

6

@Dan503 正如 kitsonk 指出的那样，除非你指定，否则 Deno 不会解析任何类型的元数据

但不要把它看作是一个缺点，因为你实际上摆脱了编译器的假设，并且可以选择tsconfig在文件夹中执行多项操作，以达到不同的目的

它们甚至不需要命名tsconfig就能被 Deno 解析

Soremwar

6

我期望它会默认tsconfig.json像其他工具一样使用，并且您可以使用以下方法明确定义不同的配置：

--config something-else.json

Dan503

6

@Dan503 这些都是 Node 工具。Deno 哲学旨在尽可能简单直接，因此...没有不必要的抽象

Soremwar