tsconfig.json 生成器
指导
tsconfig.json 生成器
生成一个有效的 tsconfig.json 用于 TypeScript 项目，无需记忆选项名称或查阅发布说明以了解最新编译器的变更。选择一个预设（Node ESM、Node CommonJS、React、Next.js、库或最严格），调整严格性开关，添加路径别名，并将生成的 JSON 文件复制到项目的根目录。
TypeScript 的编译器配置是一个复杂的表面：选项名称是大小写敏感的，选项列表在每次发布时都会增长，拼写错误或已弃用的键可能会静默生成错误输出，而不是快速失败。一个基于表单的生成器，仅输出你勾选的选项，是最快获得与项目运行时和构建流程匹配的配置的方法。
如何使用
- 打开 预设配置文件 下拉菜单并选择最符合你项目的配置。表单会为目标、模块系统、JSX 模式和推荐标志填充合理的默认值。
- 调整 语言与模块 部分，如果运行时需要不同的
target,module， 或者moduleResolution。设置jsx如果你编译 React。 - 设置 项目布局 字段（
rootDir,outDir,baseUrl）以匹配你的文件夹结构。按每行一个格式添加路径别名作为alias=target（例如@/*=src/*). - 使用 严格性 且 检查 勾选框以启用单个编译器检查。
strict一键启用完整的严格家族。 - 这 输出与互操作 部分控制文件的生成方式以及默认导入的行为。启用
declaration用于库，或noEmit当打包器处理输出时。 - 将输出面板中的生成配置复制，或直接下载为
tsconfig.json.
特征
- 预设配置文件 – Node（ESM 和 CommonJS）、React、Next.js App Router、库，以及为新项目提供的最严格配置文件。
- 所有现代目标版本 – 从 ES5 到 ES2023 加上 ESNext，包含匹配的模块系统，如 NodeNext 和打包器解析。
- 路径别名构建器 – 每行输入一个别名；当存在别名时，生成器会自动连接
baseUrl。 - 细粒度的严格性 – 切换
noUncheckedIndexedAccess,exactOptionalPropertyTypes，以及其他个别严格家族标志。 - JSX 支持 – 选择之间
react-jsx,react-jsxdev，经典react， 或者preserve用于打包器。 - 内联注释 – 每个选项都可以附带简短说明，以便生成的文件能够自我文档化。
- 包含和排除通配符 – 多行输入用于
include且exclude模式，每个预设都有合理的默认值。 - 库模式 – 库预设开启
declaration,declarationMap，并且sourceMap，以便消费者获得完整的类型。 - 复制或下载 – 一键将结果放入你的仓库。
常问问题
-
tsconfig.json 是什么？TypeScript 为什么需要它？
tsconfig.json 是 TypeScript 编译器读取的配置文件，用于决定哪些文件属于一个项目以及如何编译它们。该文件存在于某个目录中，表示该目录是 TypeScript 项目的根目录。如果没有该文件，编译器仍可处理单个文件，但像编辑器、构建流程和代码检查插件等工具依赖它来共享一致的代码视图、目标运行时环境以及类型检查的严格性。
-
模块和模块解析之间的区别是什么？
模块控制 TypeScript 发出的 JavaScript 语法——例如 CommonJS 的 require/exports、ES 模块的 import/export，或像 NodeNext 这样的混合模式。模块解析是独立的，它控制着导入规范在磁盘上的查找方式——例如，一个没有扩展名的导入是否解析为 .ts 文件，是否尊重 package.json 中的导出字段，以及是否假设使用打包器风格的解析器。现代项目中，如果使用打包器，通常会将 module: ESNext 与 moduleResolution: Bundler 配合使用；而纯 Node 项目且没有打包器，则会将 module: NodeNext 与 moduleResolution: NodeNext 配合使用。
-
strict 实际上启用了哪些功能？
strict 是一个元标志，它通过一个开关启用完整的严格家族功能：noImplicitAny、strictNullChecks、strictFunctionTypes、strictBindCallApply、strictPropertyInitialization、noImplicitThis、alwaysStrict 和 useUnknownInCatchVariables。未来编译器版本中新增的严格标志也会自动包含在内。虽然仍可以显式设置个别标志以覆盖默认的严格设置，但大多数新项目应保持 strict 开启，并额外添加更严格的选项，如 noUncheckedIndexedAccess。
-
路径别名如何与 baseUrl 配合工作？
paths 定义了从导入规范到实际文件位置的映射，查找是相对于 baseUrl 进行的。例如，baseUrl: "." 和 paths: { "@/*": ["src/*"] } 表示从 @/utils 导入会解析到 ./src/utils。路径别名仅影响类型检查；打包器、测试运行器和运行时需要其自身的等效配置（如 Vite resolve.alias、Jest moduleNameMapper、Node imports 字段）才能在运行时实现相同的路径效果。
-
在什么情况下应启用 noEmit？
noEmit 适用于由其他工具（通常是像 Vite、esbuild、webpack 或 Next.js 这样的打包器）生成 JavaScript 输出的项目，而 TypeScript 仅用于类型检查。当 noEmit 开启时，编译器会验证类型但不会生成任何文件。它在 CI 环境中也非常有用，可以实现快速的类型检查步骤。对于发布到 npm 的库项目，应保持 noEmit 关闭，以便编译器可以同时生成 .js 和 .d.ts 文件以及源代码。
