本技能用于指导如何从 npm 包发布 TypeScript 声明，使消费者能够真正解析到类型。核心原则：任务不是让 package.json 拥有 types 字段就算完成，而是当全新消费者安装你实际将要发布的 tarball 后，每一个可导入的入口点都能获得类型。
用途与流程 工作按固定顺序推进，每一步都有必须通过的检查：
- 预检：在编辑前一次性记录仓库根目录与目标包的绝对路径、包管理器（依据 lockfile 而非习惯）、声明的与实际使用的 Node 版本、已存在的工具（typescript、打包器、publint、@arethetypeswrong/cli）、生命周期脚本（prepare、prepack、prebuild、pretest、build、test、watch:*）、monorepo 中需先构建的兄弟包。每条命令都要显式指定目录，避免依赖上一条命令留下的工作目录。
- 清点全部公共入口点：读取 main、module、browser、types/typings、exports 的每个键（包括 "./browser"、"./api"、"./cli"、通配符等）及其内部条件（import、require、node、browser、default），以及 typesVersions；没有 exports 映射时，还要枚举消费者已在使用的深层路径。仅修复 exports["."] 是最常见的失败。
- 生成声明：在现有构建体系上启用声明输出（tsc 的 declaration、tsup 的 dts、vite-plugin-dts、rollup-plugin-dts、esbuild 需配合 tsc --emitDeclarationOnly、api-extractor 等），不要另起一套并行构建；按实际安装版本配置插件；tsc 不会复制手写 .d.ts 输入；只为已发布源码生成声明；noEmit 为 true 的 tsconfig 不要改动，改用单独的构建配置；新增构建依赖要同步更新 lockfile。
- 路由入口点到声明：在每个格式分支内、default 之前设置 types 条件，default 必须在对象中最后；声明扩展名要与 JS 入口对应（.js→.d.ts、.mjs→.d.mts、.cjs→.d.cts）；Node10 旧式解析忽略 exports，依赖顶层 types 与 typesVersions 指向 CJS 声明。
- 确保声明进入 tarball：检查 package.json 的 files（含否定规则）、.npmignore、.gitignore 以及构建清理步骤四类过滤；用 npm pack 生成真实 tarball，并用 tar 列出 .d.ts/.d.mts/.d.cts 逐项断言路径存在。
- 以消费者身份验证：对 tarball 运行 publint 与 @arethetypeswrong/cli（若只跑一个，选 attw，它能发现无类型的子路径、缺少 CJS 声明的 require 条件、ESM 声明冒充 CJS 等问题）；把报告写入文件后阅读，不以 || true 掩盖退出码；工具异常时按症状分类处理，必要时改用打包消费者校验脚本，并运行仓库已有的类型测试。
- 证明未破坏构建：启用声明输出会暴露此前没有的错误（如外部模块名称无法命名、推断类型引用私有符号、内部调用 tsc 的工具的弃用错误），需按改动内容运行相应检查，避免重复运行生命周期脚本。
适用场景 适用于为 npm 包添加 types/typings、发布类型声明、排查消费者无法解析类型或子路径无类型等问题，尤其是多入口、多格式（ESM/CJS）、monorepo 与需兼容 Node10 解析的包。
限制与注意事项 资料未提供收费、价格、平台支持范围等信息。技能本身不改变包的功能语义；声明发布后仍需以真实 tarball 验证，不能仅凭源码或 package.json 判断；attw 在包支持的模式下报错必须修复或明确报告为未解决失败，不得静默忽略；不要为了让检查告警消失而添加元数据或重构 exports。