吐槽 tsc 的几大罪状

[molvqingtai]

1. 2024 年了，tsc 编译出的 js 代码还不能直接在任何 js runtime 中运行

输入文件 index.ts

import foobar from 'foobar'

你以为的输出 index.js

import foobar from 'foobar.js'

实际输出 index.js

import foobar from 'foobar'

？？？ tsc 编译出的 js 代码居然是坏的，没有 .js 扩展名，根本不能运行

如果你觉的上面的结果是 tsc 为了不破坏用户代码的语义，那么此时你肯定想我加上 .ts 就好了。

修改 index.ts

import foobar from 'foobar.ts'

就...好了？？？

不好意思，tsc 版本低于 5.0 根本不支持导入 .ts 后缀的文件，ts 编译器居然不支持导入 ts 文件？？？

好了，你说我大不了升级版本到 5.x 吧

完事之后你就会遇到一个错误，让你在 tsconfig 中配置 allowImportingTsExtensions: true

等你刚配置完又报错了，提示你必须配置 noEmit 或 emitDeclarationOnly

啥？？？，我这一通折腾不就是为了输出正确的 js 代码？

让我配置 noEmit 不输出 js 代码只输出类型文件，我还编译个啥？

2. tsc 配置项超多，此处 webpack 笑而不语

3. tsc 是目前前端工具链中最慢的一环了吧....

使用 esbuild 编译，tsc 检查类型

npm run build

✔ build success 784ms

✔ check success 17s

[molvqingtai]

5.0 之所以支持导入 .ts 还是因为 Deno

作者迫不得已才选了一种折中方式（开启此选项无法输出 js 文件）,虽然有无数开发者都提了关于输出 .js 和导入 .ts 的 issues

但是作者 bababab...一大堆得到的回复是永远不会支持重写导入文件的后缀

[zhy0216]

试试 bun 开箱即用

tsc 慢是因为 js 作为动态语言慢
可以看看 stc rust 写的

[zhy0216]

不过难度太大没有金主
不看好 stc...

[chuck1in]

@zhy0216 这个 ts 和 js 还有那个什么 cjs 和 es 的模型，真的很令人头疼。我觉得还 bun 最大的好处就是在用不用操心这些破事。其他的所谓速度快那些都是其次的问题。

[june4]

第一条，ts 当然不能直接修改你的语义，你 import 的是'foobar'，不是'foobar.js', 你要'foobar.js'，你不能自己在 ts 源代码里加 .js 吗？ ts 现在追求的就是尽量靠近 js 只加类型修饰，去了修饰就是纯 js.

[xujiabin]

试了下,编译出的 js 可以正常跑, 虽然不是楼主想要 样子
t.ts
--
import {an} from './h'
编译后 生成
t.js
---
"use strict";
exports.__esModule = true;
var h_1 = require("./h");

[pursuer]

你也说了 tsc 要检查类型，tsc 还带有 lsp 的，不然你全程用 esbuild?。

[euronx]

如果包名就叫 foobar 呢？
如果把 import foobar from 'foobar' 输出位 import foobar from 'foobar.js' 那才是真的有问题

[web1996]

类型文件导入时不能使用路径简写，不然输出的.d.ts 路径不会转换，目前没有找到完美解决方案。

[skkakaka2]

我都看傻了…………from 后面不是包名吗？为什么要加后缀？？如果是 js 文件的话肯定是路径引用啊，你这又没路径的直接加后缀怎么会不报错？？？