我的 tsconfig.json 配置

前言

牛马人拖了两个月的更新，滑跪入场~
先把之前vue ts 谁人项目的一些项目配置什么的，补充完整，能让大家少走弯路，是最好滴~
相关文章

1.【项目配置文件】TypeScript 编译器的配置文件
我的 tsconfig.json 配置

1. {
2.   "compilerOptions": {
3.     // 指定输出 ECMAScript 版本，默认为 es5
4.     "target": "ESNext",
5.     "useDefineForClassFields": true,
6.     "module": "ESNext",
7.     "moduleResolution": "Node",
8.     "strict": true,
9.     "jsx": "preserve",
10.     "sourceMap": true,
11.     "resolveJsonModule": true,
12.     "isolatedModules": true,
13.     "esModuleInterop": true,
14.     "types": [
15.       "node",
16.       "vue-router"
17.     ],
18.     // "suppressImplicitAnyIndexErrors":true,
19.     "lib": [
20.       "ESNext",
21.       "DOM"
22.     ],
23.     "skipLibCheck": true,
24.     // 模块解析根路径，默认为 tsconfig.json 位于的目录
25.     "baseUrl": ".",
26.     "paths": {
27.       "@/*": [
28.         "src/*"
29.       ],
30.     }
31.   },
32.   "files": [],
33.   "include": [
34.     "src/**/*.ts",
35.     "src/**/*.d.ts",
36.     "src/**/*.tsx",
37.     "src/**/*.vue",
38.   ],
39.   "references": [
40.     {
41.       "path": "./tsconfig.app.json"
42.     },
43.     {
44.       "path": "./tsconfig.node.json"
45.     }
46.   ]
47. }

复制代码

以下是对我的 tsconfig.json（TypeScript 项目配置文件）中各配置项的具体解释：
（可以就看对自己有用的部门）
一、compilerOptions（编译器选项）部门

1） "target": "ESNext"

• 含义：指定 TypeScript 编译后输出的 ECMAScript 版本目的为 ESNext。ESNext 表现会利用最新的 ECMAScript 标准特性（例如在编写代码时可以利用最新提案中的语法等），而不是像默认的 es5 那样输出兼容旧版本浏览器或环境的代码。
  

   如果你的运行环境支持较新的 JavaScript 特性，就可以利用这些新特性来编写更简洁、高效的代码，不外对于一些旧环境可能须要额外的转译等处置惩罚才能运行。
  

• 示例场景：若想利用可选链（?.）、空值归并运算符（??）等较新的语法，设置为 ESNext 就能直接在 TypeScript 代码中利用，编译时也会按对应新特性进行输出（前提是目的运行环境支持）。
  

2） "useDefineForClassFields": true

• 含义：这个选项改变了类字段（class fields）的初始化行为。当设置为 true 时，类中声明的实例字段会以严格模式下定义的方式进行初始化，更符合最新的 JavaScript 类相关规范，有助于确保类字段在利用时的行为符合预期，避免一些潜在的与类属性初始化和赋值相关的题目。
  
• 示例场景：在定义类时，其属性的初始化和赋值逻辑会遵循新的规范，例如：
  

1. class MyClass {
2.   myField = 10; // 这里的初始化行为会按照严格模式下的定义方式处理
3. }

复制代码

3） "module": "ESNext"

• 含义：用于指定模块体系的格式，选择 ESNext 意味着会接纳最新的 ECMAScript 模块标准（如 import 和 export 的语法形式）来处置惩罚模块相关的代码。它与 target 选项配合，使得项目可以在支持新模块规范的环境中利用更简洁、原生的模块机制，而不是利用旧的如 CommonJS 等模块格式（固然，在实际应用中可能还须要考虑兼容性及打包等环境）。
  
• 示例场景：代码中可以直接利用类似 import { something } from './module.js'; 这样符合最新模块语法的写法，并且编译输出也会按此标准来处置惩罚模块间的引用关系。
  

4） "moduleResolution": "Node"

• 含义：决定了 TypeScript 编译器怎样剖析模块导入的路径，设置为 Node 表现会按照 Node.js 的模块剖析策略来查找和加载模块。这意味着它会先在当前目次下查找 node_modules 文件夹中的模块，然后按照一定层级向上查找，类似于 Node.js 运行环境中 require 函数查找模块的方式（但这里针对的是利用 import 等模块语法的环境）。
  
• 示例场景：当在代码中写 import { someFunction } from 'lodash'; 时，编译器会按照 Node.js 的模块查找逻辑去定位 lodash 模块的实际位置，便于精确引入和利用第三方模块。
  

5） "strict": true

• 含义：启用严格模式下的所有类型检查选项，这是一种保举的开发实践，可以资助捕获更多潜在的代码错误，比如未声明变量的利用、隐式的 any 类型（变量没有明确类型声明时）、不答应对 null 或 undefined 进行不安全的操作等。启用严格模式能让代码更健壮、更易于维护和理解。
  
• 示例场景：如果有一个变量没有声明类型且没有初始赋值，在非严格模式下可能不会报错，但在 strict 为 true 时，TypeScript 编译器会提示错误，促使开发者明确变量的类型信息。
  

   严格模式，大家可以看个人需求开不开，不必照搬我的，我代码校验的严格程度开太高了，差点打包失败，emm，不介意学习哦~
  6） "jsx": "preserve"

• 含义：配置怎样处置惩罚 JSX 语法（常用于 React 等前端框架中用于描述 UI 组件结构的语法）。preserve 值表如今编译过程中，会保存 JSX 语法不进行转换，通常是留给后续的构建工具（如 Babel 等）大概框架特定的编译步骤去处置惩罚，这样可以灵活地与差别的前端构建和渲染流程配合。
  
• 示例场景：在利用 React 开发应用时，代码中编写的 <MyComponent /> 这样的 JSX 表达式在 TypeScript 编译阶段会原样保存，等待后续环节进一步处置惩罚成可在浏览器中运行的 JavaScript 代码来渲染组件。
  

7） "sourceMap": true

• 含义：开启天生 source map 文件，source map 是一种映射关系文件，它可以将编译后的代码（如 JavaScript）与原始的 TypeScript 代码关联起来。在调试时，浏览器等调试工具可以借助 source map 文件，让开发者能够在原始的 TypeScript 代码层面进行断点调试等操作，而不是只能调试编译后的 JavaScript 代码，极大地方便了开发过程中的调试工作。
  - 示例场景：当项目运行出现题目，在浏览器开发者工具中进行调试时，能够看到并操作对应的 TypeScript 代码，精确地定位代码中的题目所在，即使实际实行的是编译后的 JavaScript 文件。
  

8） "resolveJsonModule": true

• 含义：答应在 TypeScript 代码中直接导入 .json 文件并将其作为模块利用，编译器会剖析 .json 文件内容并将其转换为对应的 JavaScript 对象类型，使得在项目中利用配置文件（通常是 JSON 格式）等操作更加方便和自然，就像导入其他 JavaScript 模块一样对待 .json 文件。
  
• 示例场景：如果有一个 config.json 文件存储项目配置信息，在 TypeScript 代码中可以利用 import config from './config.json'; 来获取其中的配置内容并利用，方便进行项目配置的读取和管理。
  

9） "isolatedModules": true

• 含义：这个选项强制每个文件都要作为独立的模块进行处置惩罚，它有助于确保每个模块的代码都可以独立编译和理解，并且可以防止一些跨模块的、可能导致编译不兼容或难以理解的复杂依赖环境。通常在一些模块构建和打包工具的场景下利用，确保模块的独立性和可移植性。
  
• 示例场景：每个 .ts 文件的代码编写都要保证可以独立编译和运行，不能依赖一些编译时的全局状态大概非标准的跨模块引用方式，有助于提升项目代码的模块化质量和可维护性。
  

10） "esModuleInterop": true

• 含义：解决了在 TypeScript 中利用 CommonJS 模块和 ECMAScript 模块相互兼容的一些题目，使得从 CommonJS 模块导入内容到 ECMAScript 模块（大概反之）时，语法和行为更加符合预期，避免出现类型错误大概运行时不兼容的环境，方便在项目中混合利用差别模块规范的模块。
  
• 示例场景：如果项目中既引入了遵循 CommonJS 规范编写的老的 Node.js 模块，又有接纳最新 ECMAScript 模块规范的新模块，开启这个选项可以让它们之间的交互和导入操作更加顺畅。
  

11） "types": ["node", "vue-router"]

• 含义：指定了要包含的类型声明文件（.d.ts）的模块名称，这里告诉编译器在编译时要加载 node（用于 Node.js 相关的类型声明，比如 process 对象等的类型定义）和 vue-router（用于 Vue Router 库相关的类型定义，方便在利用 Vue Router 时进行类型检查等操作）的类型声明文件，以便进行精确的类型检查和代码提示。
  
• 示例场景：在利用 Node.js 的内置模块大概 Vue Router 的 API 时，编辑器能够根据这些类型声明提供精确的代码补全、参数类型提示以及检测是否精确利用了相关函数和对象等，提升开发效率和代码质量。
  

12）"lib": ["ESNext", "DOM"]

• 含义：定义了编译时默认包含的内置类型声明库，这里选择了 ESNext（最新的 ECMAScript 标准相关类型声明，如新的全局对象、函数等的类型定义）和 DOM（用于浏览器环境中 Document Object Model，即网页文档对象模型相关的类型声明，像 document、window 等对象的类型定义）。这意味着编译器在进行类型检查等操作时，会基于这些库中的类型定义来判定代码是否精确，同时也使得在代码中可以直接利用相关的标准和浏览器环境下的对象及函数，并且有类型支持。
  
• 示例场景：当在代码中利用 document.getElementById 这样的 DOM 操作函数时，编译器能根据 DOM 类型库中的定义来检查参数类型是否精确、返回值类型是否符合预期等；同样，对于利用最新 ECMAScript 特性相关的代码也能进行精确的类型检查。
  

13）"skipLibCheck": true

• 含义：跳过对所有声明文件（.d.ts）的类型检查，通常环境下，TypeScript 会检查引入的类型声明文件是否精确、有无类型冲突等环境，但开启这个选项后，为了进步编译速率，会直接跳过这些检查。
  

   不外这可能会导致一些潜在的类型相关题目被忽略，以是须要谨慎利用，一般在确定引入的类型声明文件比力可靠大概更注重编译效率时可考虑开启。
  

• 示例场景：在大型项目中，引入了大量第三方库的类型声明文件，而你对这些库的类型精确性比力有信心，大概编译时间过长想加速编译速率时，可以开启这个选项，让编译器不去具体检查这些声明文件的类型环境。
  

14）"baseUrl": "."

• 含义：指定模块剖析的根路径，这里设置为 .（表现当前目次），意味着当剖析模块导入路径时，会以当前项目所在的目次作为基础来查找模块。这与 paths 等配置项配合，用于定义相对路径的模块查找方式，方便构造项目的模块结构和导入关系。
  
• 示例场景：联合 paths 配置，如果定义了 @/* 对应 src/* 的路径映射，那么在代码中写 import { something } from '@/module'; 时，编译器会从项目的 src 目次下查找对应的 module 文件或模块，以当前项目目次作为起点进行模块路径的剖析。
  

15） "paths": { "@/*": ["src/*"] }

• 含义：用于创建模块路径的别名映射，这里定义了 @ 别名，它对应的实际路径是 src 目次及其子目次（src/*）。这样在代码中就可以利用简洁的 @ 开头的路径来导入模块，而不用写相对较长且容易堕落的相对路径，使得模块导入的代码更加清晰、易读，同时也方便项目目次结构调解时同一修改模块导入路径。
  
• 示例场景：在一个 Vue 项目中，组件、模块等文件分布在 src 目次下的差别子目次中，利用 import MyComponent from '@/components/MyComponent.vue'; 这样的写法，相比于写 import MyComponent from '../../components/MyComponent.vue'; （假设相对路径环境）更加简洁明白，而且后期如果 src 目次结构有变革，只须要调解 paths 配置里的映射关系即可，不用在每个导入代码处修改相对路径。
  

二、files 部门

• "files": []：这个数组可以用来明确指定要编译的单个文件列表，如果为空数组（像这里的环境），则表现不通过这个配置项来指定具体文件，而是依赖 include 和 exclude 等配置项来确定哪些文件须要被编译。
  
• 通常在只想编译特定的几个文件，而不是按照目次等规则来确定编译范围时，可以在这个数组里添加具体的文件路径（如 "./src/main.ts" 等）。
  

三、include 部门

• "include": ["src/**/*.ts", "src/**/*.d.ts", "src/**/*.tsx", "src/**/*.vue"]：
  
  
  
  • 含义：定义了要包含在编译范围内的文件或文件目次的通配符模式，这里表现会将 src 目次及其所有子目次（** 表现恣意层级的子目次）下的 .ts（TypeScript 文件）、.d.ts（类型声明文件）、.tsx（包含 JSX 语法的 TypeScript 文件）和 .vue（Vue 单文件组件，在 Vue 项目中常用，其 <script> 部门可能包含 TypeScript 代码）这些类型的文件都纳入编译的范围，让编译器对这些文件进行类型检查、编译等操作。
    
  • 示例场景：在一个 Vue + TypeScript 项目中，只要符合上述文件类型且位于 src 目次及其子目次内的文件都会被处置惩罚，确保项目中相关的代码都能颠末 TypeScript 的编译流程，保障代码质量和类型安全性。
    
  
  

四、references 部门

• "references": [ { "path": "./tsconfig.app.json" }, { "path": "./tsconfig.node.json" } ]：
  
  
  
  • 含义：用于引用其他的 tsconfig.json 文件，这里表现当前的 tsconfig.json 文件会引用同目次下的 tsconfig.app.json 和 tsconfig.node.json 这两个配置文件。通常在项目有差别的编译配置需求场景下利用，比如一个项目中针对应用步调代码和针对 Node.js 相关代码（例如服务器端渲染等环境）可能有差别的编译设置，通过这种引用关系，可以更好地构造和复用差别部门的配置内容，保持配置的清晰和可维护性。
    
  • 示例场景：假设 tsconfig.app.json 专门用于配置前端应用相关的 TypeScript 编译选项，而 tsconfig.node.json 用于配置后端 Node.js 服务部门（如果项目有这样的架构）的编译选项，当前的主 tsconfig.json 通过引用它们来整合整个项目的编译配置管理。
    
  
  

   差别的项目根据自身需求（如框架利用、运行环境、代码构造等环境）可以对这些配置项进行适当的调解和优化。 不用如出一辙，不用如出一辙，不用如出一辙！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。