求助:TS 路径别名在 Vercel 构建报错
本地 @/ 路径别名跑得好好的,推到 Vercel 构建直接报 "Cannot find module '@/lib/db'"。tsconfig 里 paths 配了, baseUrl 也写了,VS Code 不报错。 折腾半天发现要么是 .gitignore 漏了某个 exte
Posts
像论坛一样发起讨论,适合问题、观点、工具推荐和经验交流。
本地 @/ 路径别名跑得好好的,推到 Vercel 构建直接报 "Cannot find module '@/lib/db'"。tsconfig 里 paths 配了, baseUrl 也写了,VS Code 不报错。 折腾半天发现要么是 .gitignore 漏了某个 exte
TS 5.0 加了 const 泛型参数,之前要靠 as const 才能保留的字面量类型,现在调用时自动收窄。 写工具函数时终于不用强制要求调用方写 as const 了,对 API 设计友好很多。 唯一不爽的是调用点语法有点丑,可读性一般。 大家有用到这个特性吗?
接手一个老项目, any 满天飞,光类型错误就有 2000 多个。开启 noImplicitAny 直接全红,团队根本没人敢动。 我的渐进治理思路: 先开 skipLibCheck ,把第三方 .d.ts 排除。 把 any 临时改成 unknown ,强制使用前收窄。 高频模块
Server Actions 的入参校验一直是个头疼事,最近全面接入了 Zod,体验明显好。 好处是 schema 和类型同源,再也不用两边维护。配合 react hook form 的 resolver,表单校验也复用同一份。 不爽的点: 运行时校验有性能开销,热点路径要测。
Tailwind v4 把配置全改成 CSS first, tailwind.config.js 基本不用了,主题写在 CSS 里。升级的时候踩了不少坑。 自定义颜色要从 theme 函数改成 @theme 块。 插件系统大改,老插件基本都得换。 Content 配置自动检测了,
团队新项目在选样式方案。我个人偏 Tailwind(不用起类名,复用方便),但有几个老成员觉得 utility class 像 "在 HTML 里写 CSS",可读性差。 我的看法: 小到中型项目、组件复用多 → Tailwind 真香。 设计系统复杂、需要强语义 class →
项目里不少同事为了 "可读性",喜欢在 .css 里用 @apply 把 utility 拼成语义 class。表面上干净了,但我觉得这违背了 Tailwind 的初衷。 问题: 失去了 utility first 的就地可读性。 purge 之外的地方容易出问题。 维护时既要懂
一个 800+ 组件的中后台项目,dev 启动从 webpack 时代的 90s 降到 Vite 的 3s,但页面越来越多后发现冷启动后第一次访问某些大页面还是会卡几秒。 靠 esbuild 的依赖预构建,大部分场景已经很快了。卡顿主要出现在巨型 route chunk 的首次加
Next.js 15 把 Turbopack 标记 stable,dev 性能确实猛。但我的非 Next 项目(纯 Vite + React)用不上 Turbopack,犹豫要不要迁。 实际对比: Turbopack:仅限 Next 生态,dev 飞快,但插件生态不如 Vite。
接手一个内容站,LCP 4.2s,用户反馈巨卡。三个月逐步压到 1.5s,记录下关键手段。 字体改 self host + font display: swap,省了 600ms。 首屏图片用 next/image + priority,LCP 元素提前加载。 第三方脚本(统计、
团队在吵要不要全面上 next/image 。它确实解决了懒加载、格式转换、尺寸适配,但代价也不小: 必须配 loader,自托管图片要走 sharp,构建慢。 第三方图片要配 remotePatterns,CSP 也要调。 老页面批量改造工作量大。 我的结论:内容站、图片多的电
一直用 Google Fonts,最近被安利自托管。实测了一下,自托管首屏能快 300 500ms(少了一个第三方连接),CLS 也更可控。 代价是字体文件要自己维护、版权要自己确认。中文字体更麻烦,体积大,得做 subset。 我们的做法是:英文用 next/font(Goog