date-fns 4.2.0 装好后，TypeScript 找不到类型声明

升级到 date-fns 4.2.0 后，原来的 TypeScript 项目突然无法解析 date-fns 类型；退回 4.1.0 又恢复。遇到这个明确版本组合，先检查安装包里的声明文件，不要先把业务中的日期类型改成 any。

4.2.0 的发布物缺少正常入口所需的 TypeScript 声明。JavaScript 文件仍可存在，因此“运行时能导入”和“TypeScript 能获得声明”可以出现不同结果。

exports 指向文件，不代表文件真的装进来了

包的 package.json 会声明类型入口，子路径也可能有自己的 types 条件。需要把这些映射与实际安装目录对照。若映射指向的文件不存在，切换 import 写法或反复调整 moduleResolution，不能凭空生成对应声明。

正式 4.2.0 发布物中，主入口所需的声明缺失；4.2.1 已包含对应声明，当前正式 4.4.0 也保留类型文件。这是发布文件层面的差异，不应误写成 date-fns 从此不再支持 TypeScript。

先保留编译错误、锁文件里的实际版本，以及项目从哪个工作区解析到这个依赖。单仓库中有多个副本时，根目录看到一个完整版本，不代表失败的包使用同一份。

把受影响依赖换到含声明的正式包

如果当前锁定在 4.2.0，可沿项目现有的依赖更新流程采用 4.2.1 或经过兼容性检查的后续正式版本。使用原来的包管理器更新并保留锁文件变更，再核对失败工作区最终解析的版本和文件。

下面是普通命名导入的示例，意在核对编译入口，不是让项目更换构建方式：

import { format } from 'date-fns';

export function formatDay(date: Date): string {
  return format(date, 'yyyy-MM-dd');
}

如果项目还使用独立函数子路径、locale 或 CommonJS 入口，应一起核对相应 types 条件。只让根入口不报错，不能说明所有子路径已恢复。

不要添加一条空的 declare module 'date-fns' 来“补类型”。这会把很多调用退化为 any，编译看似通过，却丢失参数与返回类型检查。skipLibCheck 主要跳过声明文件内部的检查，也不能补齐根本不存在的声明。

包装链问题与声明缺失分开处理

发布流程的增量构建可以造成声明没有进入产物，但使用者无需在业务仓库重建 date-fns 源码来修复一个已有正式包。手动把其他版本的 d.ts 复制进 node_modules，也会失去版本对应关系，并在重装后消失。

切换到完整发布物后，如果仍报错，再看 TypeScript 的模块解析方式、项目配置和路径覆盖。不要把所有找不到类型的错误都归到这次 4.2.0 发布问题。

完成更新后，用项目原有的类型检查与生产构建检查上述真实导入路径，并确认干净安装仍能得到相同声明。原来只是 Parcel 生产 bundle 中的 formatters 绑定错误，则属于运行时构建问题，不能用补类型这一处理替代。