d.ts 打包和 types 入口别留到最后

很多组件库项目在开发过程中，类型体验一直靠本地 IDE 兜底，所以团队很容易把 d.ts 打包和 types 入口这件事拖到最后处理。真正发布出去之后才发现，别人虽然能装上包，却拿不到完整类型提示，体验一下就掉下来了。

我越来越倾向尽早把类型产物当成正式输出的一部分来看。哪些声明文件要暴露、入口字段怎么指向、子路径导出有没有对应类型，这些都应该在构建链路稳定之前就跑通。只要等到发布前最后一刻才补，通常会连带改动目录结构和导出规则。

类型产物处理不清楚时，常见症状很明显：IDE 提示断断续续、默认导出和命名导出混乱、子模块导入后类型直接丢失。它们都不是“使用者环境问题”，本质上是库的交付契约没闭环。

我会把类型入口和主入口同等对待，因为对 TypeScript 项目来说，类型提示本来就是一半体验。组件库只把 JS 打出来还不够，类型也得是稳定可消费的。

越早把这件事拉到台前，后面发布时就越不会慌。

前端里的很多“体验问题”本质上都是边界问题

围绕「d.ts 打包和 types 入口别留到最后」这类前端话题，最常见的误区是先去追求框架技巧，再去补组件边界和状态来源。可一旦项目规模上来，真正让代码变脆的，往往不是少用了某个 API，而是数据获取、缓存失效、交互 pending、组件拆分和构建产物之间没有形成清楚约定。框架升级只会把这些隐性问题更快地暴露出来。

我会先做的落地检查

• 先明确状态由谁拥有、什么时候重置、什么时候延迟更新，避免组件自己偷偷维护第二份真相。
• 把路由、缓存、构建配置和产物入口拆成可独立验证的边界，不要把所有约定都留在默认行为里。
• 一旦某个点已经影响到交互一致性、渲染成本或团队协作效率，就应该把它写成约束，而不是继续靠经验口口相传。