前言
牛马人拖了两个月的更新,滑跪入场~
先把之前vue ts 那个项目的一些项目配置什么的,补充完整,能让大家少走弯路,是最好滴~
相关文章
1.【项目配置文件】TypeScript 编译器的配置文件
我的 tsconfig.json 配置
{"compilerOptions": {// 指定输出 ECMAScript 版本,默认为 es5"target": "ESNext","useDefineForClassFields": true,"module": "ESNext","moduleResolution": "Node","strict": true,"jsx": "preserve","sourceMap": true,"resolveJsonModule": true,"isolatedModules": true,"esModuleInterop": true,"types": ["node","vue-router"],// "suppressImplicitAnyIndexErrors":true,"lib": ["ESNext","DOM"],"skipLibCheck": true,// 模块解析根路径,默认为 tsconfig.json 位于的目录"baseUrl": ".","paths": {"@/*": ["src/*"],}},"files": [],"include": ["src/**/*.ts","src/**/*.d.ts","src/**/*.tsx","src/**/*.vue",],"references": [{"path": "./tsconfig.app.json"},{"path": "./tsconfig.node.json"}]
}
以下是对我的 tsconfig.json
(TypeScript 项目配置文件)中各配置项的详细解释:
(可以就看对自己有用的部分)
一、compilerOptions
(编译器选项)部分
1) "target": "ESNext"
- 含义:指定
TypeScript
编译后输出的ECMAScript
版本目标为ESNext
。ESNext
表示会使用最新的ECMAScript
标准特性(例如在编写代码时可以使用最新提案中的语法等),而不是像默认的es5
那样输出兼容旧版本浏览器或环境的代码。
如果你的运行环境支持较新的
JavaScript
特性,就可以利用这些新特性来编写更简洁、高效的代码,不过对于一些旧环境可能需要额外的转译等处理才能运行。
- 示例场景:若想使用可选链(
?.
)、空值合并运算符(??
)等较新的语法,设置为ESNext
就能直接在 TypeScript 代码中使用,编译时也会按对应新特性进行输出(前提是目标运行环境支持)。
2) "useDefineForClassFields": true
- 含义:这个选项改变了类字段(
class fields
)的初始化行为。当设置为true
时,类中声明的实例字段会以严格模式下定义的方式进行初始化,更符合最新的JavaScript
类相关规范,有助于确保类字段在使用时的行为符合预期,避免一些潜在的与类属性初始化和赋值相关的问题。 - 示例场景:在定义类时,其属性的初始化和赋值逻辑会遵循新的规范,例如:
class MyClass {myField = 10; // 这里的初始化行为会按照严格模式下的定义方式处理
}
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
通过引用它们来整合整个项目的编译配置管理。
- 含义:用于引用其他的
不同的项目根据自身需求(如框架使用、运行环境、代码组织等情况)可以对这些配置项进行适当的调整和优化。 不用一模一样,不用一模一样,不用一模一样!