【typescript】Vue CLI4创建vue项目

在vue项目中使用ts，有两种方式：

1.全新项目：使用vue cli4脚手架创建vue项目时，选中typescript，会自动配置好ts相关环境。开箱即用。
2.已有项目：使用vue cli4添加vue官方配置的ts相关插件。
vue add typescript

当前操作环境

$ node --version
v12.22.1
$ npm --version
6.14.12
$ yarn --version
1.22.5
$ vue --version
@vue/cli 4.5.13

vue cli4自动完成了那些ts配置

这里我们主要看一下vue cli4脚手架自动配置了那些ts配置

1.安装依赖

dependencies 依赖

"vue-class-component": "^7.2.3",//提供使用Class 语法写Vue组件
"vue-property-decorator": "^9.1.2"//在Class语法基础上提供一些辅助装饰器。增强的class 描述组件的工具

devDependencies 依赖

"@typescript-eslint/eslint-plugin": "^4.18.0",//使用ESlint 校验 Typescript 代码。其实ts有自己的校验工具，tslint，但是不好用，所以大多是使用eslint+该工具来校验
"@typescript-eslint/parser": "^4.18.0",//将ts转为 AST 供Eslint 校验使用。是@typescript-eslint/eslint-plugin中内部使用的插件
"@vue/cli-plugin-typescript": "~4.5.0",//是vue-cli的一个插件，将ts相关的工具集成起来，将ts+ts-loader+fork-ts-checker-webpack-plugin 集成，进行更快的类型检查，是一个统一的集成调度者。
"@vue/eslint-config-typescript": "^7.0.0",//为eslint 提供关于ts的校验规则
"typescript": "~4.1.5"//typescript编译器，提供类型校验和转换js功能

2. 生成ts配置文件`tsconfig.json`

默认已经配置了许多可以开箱即用的功能

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "strict": true,
    "jsx": "preserve",
    "importHelpers": true,
    "moduleResolution": "node",
    "experimentalDecorators": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "sourceMap": true,
    "baseUrl": ".",
    "types": [
      "webpack-env",
      "jest"
    ],
    "paths": {
      "@/*": [
        "src/*"
      ]
    },
    "lib": [
      "esnext",
      "dom",
      "dom.iterable",
      "scripthost"
    ]
  },
  "include": [
    "src/**/*.ts",
    "src/**/*.tsx",
    "src/**/*.vue",
    "tests/**/*.ts",
    "tests/**/*.tsx"
  ],
  "exclude": [
    "node_modules"
  ]
}

3. src下新增两个文件

shims-vue.d.ts

ts是没办法识别以.vue 结尾的模块的（eg：import xx from xx.vue，该语句ts识别不了），通过该文件做适配处理，使项目中加载.vue 模块的文件时不报错。一般不修改。该文件意思是：声明所有以 .vue结尾的文件模块，其类型都是vue构造函数。

# shims-vue.d.ts

declare module "*.vue" {
  import Vue from "vue";
  export default Vue;
}

shims-tsx.d.ts

如果要在项目中使用tsx 或者jsx 描写组件模块的话，补充了一些类型声明。如果没有这些类型声明，在jsx中使用这些成员的时候，会找不到。如果项目中没有使用jsx，可以将该文件忽略掉

# shims-tsx.d.ts

import Vue, { VNode } from "vue";

declare global {
  namespace JSX {
    // tslint:disable no-empty-interface
    interface Element extends VNode {}
    // tslint:disable no-empty-interface
    interface ElementClass extends Vue {}
    interface IntrinsicElements {
      [elem: string]: any;
    }
  }
}

4. 都是用`.ts` 后缀代替原来的`.js` 后缀

https://github.com/sorrycc/bl...

九层之台，起于累土。前端团队框架体系的建设是一个渐进式的过程，首先从基础设施开始、接着就是应用开发技术栈组合，再到组件体系，后面是上层的业务开发方案… 上层以下层为基础，共同构建出完整的框架体系。

我觉得前端团队可以按照这样的分层结构，分阶段来完成这些建设任务。

第一阶段: 前端工程化 / 基础设施
最基础的阶段，关注前端的基础设施建设。这个阶段已经比较成熟，社区上有很多开箱即用的方案，例如 Umi、Next.js、Vue-CLI、Create-React-App 等等。主要内容有:

第二阶段: 应用开发方案整合
在完善基础设施的同时，团队的应用开发技术栈组合方案也应该稳定下来，成为框架的一部分。这些组合也非常重要，它会影响上层的组件建设和业务开发。主要内容有:

第三阶段: 组件体系
组件化现在是前端主流开发模式，这里还有很多工作可以做，还有很大的提效空间。

整个组件体系也是一个分层式的结构：

基础组件。越底层，就说明可复用的程度越高、越通用。Ant-Design、Element-UI、iView、Material-UI 这些就属于基础组件库，有能力的团队也可以开发一套符合自己设计风格的组件库。
业务组件。在基础组件之上封装的、耦合自己业务的组件。它们一般从重复的业务场景中抽象出来。
区块。再往上，就很难用模块化的组件去组织了。于是有人(阿里前端)提出了‘区块’的概念，你可以认为‘区块’是：代码片段、代码示例、代码模板… 这么看来，这并不是一种新的概念? 还没完! 区块还要配套‘区块市场’才能展现它的用处。区块市场是一个代码片段分享平台，维护着大量的区块，试图覆盖大部分常见的使用场景。对于开发者来说就是找到尽量匹配自己场景的区块，拷贝过来，稍微改改就行了。这是一种 ‘Ctrl+C，Ctrl+V’ 编程哲学的完美实践啊。
页面。和区块差不多，快速生成页面和路由。约定式的路由可以给页面自动化创建带来一些便利。
布局。例如后台的整体布局。
项目。项目的整体结构。可以通过‘脚手架‘ 来快速生成项目模板。

像区块、页面生成这些操作需要一些工具辅助。例如：

生成器。生成不同级别的元件
项目(项目模板)。俗称脚手架, 支持不同的项目类型：应用、组件库、程序库、插件
页面/路由
区块
组件
数据模型
可视化工具。可视化的项目编排工具, 如飞冰。

第四阶段：打通上下游
前端只是研发流程的一环，只是前端自嗨，上下游没有资源支持，是很难走远的。

对于前端来说，通常上游指的是 UI、下游指的是后端。

对于 UI。上面说的组件体系，其实是建立在稳定的、一致的、统一的 UI 设计语言之上的。否则一切都是空谈。所以我们要求 UI 设计团队要有良好的设计规范、能和前端组件体系绑定并良性迭代。

对于后端。可以促进建立更标准的接口范式、封装通用的服务(有利于业务组件复用)、更深的有业务中台、BFF…

上下游的打通，对前端生产力的解放也有非常大的促进作用。

dragonishare