为什么vite中TS报错,可以继续运行?Webpack不行?💡

确实有可能出现标题的情况,但是原因不是 Vite 或者 Webpack ,而是它们默认的 TypeScript 处理方式不同。

Vite:默认不会做 TypeScript 类型检查

Vite 默认使用的是 esbuild 来处理 ts,而 esbuild 只做:

TS → JS 转换(去掉类型),不检查类型

例如:

js 复制代码
let a: string = 123;
console.log(a);

执行:

js 复制代码
esbuild
↓
去掉类型
↓
let a = 123;
console.log(a);

浏览器完全可以运行,但是编辑器会有一些红色波浪线提示 Type 'number' is not assignable to type 'string'

Webpack 为什么经常不行?

其实 Webpack 本身也不会检查 TS,关键在于你用了什么 Loader。

ts-loader

js 复制代码
{
  test: /.ts$/,
  loader: "ts-loader"
}

ts-loader 会执行:

js 复制代码
tsc
↓
检查类型
↓
有错误
↓
停止编译

所以会报错,导致项目启动不了。

js 复制代码
TS Error
↓
webpack compile failed

如果 ts-loader 开启 transpileOnly

js 复制代码
{
    loader: "ts-loader",
    options: {
        transpileOnly: true
    }
}

它也会变成:

只转 JS,不检查类型

Babel Loader

但有些 Webpack 项目可能不是使用的 ts-loader,而是用的 Babel Loader,其执行过程是:

js 复制代码
ts
↓
babel-loader
↓
@babel/preset-typescript

Babel Loader 也不会检查类型,其只会:

删除类型,生成 JS

例如:

js 复制代码
let a: string = 123;

直接变成

js 复制代码
let a = 123;

Babel + TypeScript 和 Vite + esbuild 的行为基本一致。

真正负责检查 TS 的是谁?

其实一直都是 tsc

也就是

js 复制代码
npx tsc --noEmit

或者

npx vue-tsc --noEmit

例如:

json 复制代码
{
    "scripts": {
        "dev": "vite",
        "build": "vite build",
        "type-check": "vue-tsc --noEmit"
    }
}

开发时:

js 复制代码
vite
↓
快速启动
↓
不检查 TS

提交代码前:

js 复制代码
npm run type-check

发现所有类型错误。

为什么 Vite 要这样设计?

因为 TypeScript 类型检查很慢,例如一个大型项目:

js 复制代码
tsc
需要 10~20 秒

而 esbuild:

js 复制代码
几十毫秒

Vite 的理念就是 ------ 把两件事情拆开:

js 复制代码
开发:
esbuild
↓↓
极速启动

类型检查:
tsc / vue-tsc
↓↓
单独执行

Webpack 以前为什么喜欢一起检查?

早期的 Webpack 项目一般都是 ------ 所有事情放在一次编译里:

js 复制代码
webpack
      │
      ├── ts-loader
      │        │
      │        ├── 类型检查
      │        └── 转 JS
      │
      └── bundle

优点:

  • 编译成功 == 类型没问题。

缺点:

  • 很慢。
  • 改一行代码也要重新检查整个工程。

现在 Webpack 项目也越来越像 Vite

很多大型项目现在都会这样配置:

js 复制代码
webpack
        │
        ├── babel-loader
        │
        └── fork-ts-checker-webpack-plugin
                 │
                 └── 单独线程检查 TS

或者:

js 复制代码
webpack
↓
babel
↓
立即启动

后台
↓
fork-ts-checker-webpack-plugin

或者

CI
↓
tsc --noEmit

也就是说:

现代 Webpack 项目和 Vite 的思路已经越来越接近:编译与类型检查解耦。

总结

方案 是否检查 TS 类型 遇到类型错误是否阻止运行
Vite(默认 esbuild) ❌ 不检查 ❌ 不阻止,仍可运行
Webpack + ts-loader(默认) ✅ 检查 ✅ 通常会阻止编译
Webpack + ts-loader(transpileOnly: true) ❌ 不检查 ❌ 不阻止
Webpack + babel-loader ❌ 不检查 ❌ 不阻止
tsc / vue-tsc ✅ 检查 ✅ 会报告所有类型错误(通常作为独立步骤或 CI)

所以这个差异,本质上不是 Vite 和 Webpack 的区别 ,而是项目采用的 TypeScript 编译链路不同导致。

相关推荐
行者全栈架构师1 分钟前
【鸿蒙心迹】让应用“悬浮“起来——闪控球(floatingBall)从接入到实战全链路(HarmonyOS 7.x)
前端·算法·架构
用户6353300254797 分钟前
Day 6|ES6+ 语法:把现代 JS 写顺手,从解构到 map / filter / reduce
前端
铁皮饭盒18 分钟前
CPU就行, 老照片变清晰, 本地部署582mb腾讯的模型, 本地部署, 过节了给长辈们变个小魔术
前端·javascript·后端
其实防守也摸鱼21 分钟前
Linux文本处理命令理论学习
linux·服务器·前端·数据库·sql·学习·安全
涛涛ing1 小时前
Chrome DevTools MCP 正式可用:AI 终于能自己开浏览器调试你的页面了
前端
after you1 小时前
【无标题】
前端·javascript
酷炫码神1 小时前
Day 6|ES6+ 语法:把现代 JS 写顺手,从解构到 map / filter / reduce
前端·javascript·es6
Shockang1 小时前
TanStack Router 实战:URL 校验、Loader 与路由权限
typescript·react·路由·前端开发·tanstack router
lemon_sjdk1 小时前
从一段真实的 Electron IM 前端代码,看高级前端的工程化修养
前端·electron·状态模式·im
IT_陈寒2 小时前
Vite性能优化完全指南
前端·人工智能·后端