Flow
Flow 的意义
Flow 是 Facebook 开源的一个 JavaScript 静态类型检查工具, 作用类似 TypeScript, 但是它不像 TS 那样是一门独立的语言, 而是作为一个 babel-plugin, 借助 babel 的编译切入 JavaScript 的编码当中, 同时, 与 ts 不同的是, Flow.JS 的类型检查不是强制的, 可以通过 //@flow 手动开启, 意味着, 你可以自由选择某个文件是否开启类型检查.
Flow 真是眼前一亮, 我就想, TypeScript 挺好的, 但或许也给人带来了一些烦恼, 一旦用了 TS, 就意味着任何时候都要强制类型检查, 我觉得, 选择 JavaScript 还是 TypeScript 就变成了这样一个问题: 我们手头 1000 元, 我们到底是买一件一万元的比较喜欢的还耐用的衣服呢? 还是买一件很便宜但是又不耐用的地摊货呢?(耐用指的是维护性), 但 Flow 帮我们找到了折中方案: 类型检查这东西, 我们在想用和需要用的时候用, 同时不想用也可以不用, 就好比就是手里有 1000 块, 那我们就刚好去买 1000 块钱的衣服
Flow 的使用
- //@flow
- // 数字
- functionflow1(x:number){
- console.log(x);
- }
- flow1(2);
- // 字符串
- functionflow2(x:string){
- console.log(x);
- }
- flow2("xxx");
- // 可选参数
- functionflow3(x:?string){
- console.log(x);
- }
- flow3();
- // 多个值
- functionflow4(x:"a"|"b"|"c"){
- console.log(x);
- }
- flow3("a");
- // 任意值
- functionflow5(y:any){
- console.log(y);
- }
- flow3("a");
- // 数组
- let arr:Array<boolean>=[true,false,true];
Flow 的优点
自由和 [可选] 的类型检查风格
轻量化的类型检查, 满足一些基本要求, 同时容易学习上手
借助 babel,webpack 集成到 JS 代码中, 在当今前端社区中, 这种方式非常容易被大家所理解和接受, 同时也容易集成到已有的项目中
Flow 的缺点
这家伙简直和 JS 一毛一样, 既有有好用的优点, 同时呢, 却也有一些明显的缺点.
编辑器或 IDE 集成度低, 比如, 比如基本的变量提示功能
社区力量较弱, 库的数量较少
库的类型定义质量不高, 无法完全满足开发需求
FacebookFlow 团队的 roadmap 也并不是很清楚
Flow 的安装(Webpack 集成)
(注意: 你需要确保你有一个可运行的 webpack 配置, 同时在 module.rules 配置项中引入了 babel-loader 解析所有 JS 文件)
过程
下载 VScode 扩展插件: FlowLanguageSupport, 以在 IDE 中支持
安装 plugin-transform-flow-strip-types 插件, 运行以下命令
NPM install @babel/plugin-transform-flow-strip-types
4. 创建. babelrc 文件, 写入以下配置
- {
- "plugins":[
- "transform-flow-strip-types"
- ]
- }
5. 运行以下命令, 安装 flow 命令行
NPM install -g flow-bin
6. 在每次启动项目前都检查 Flow 是否有报错, 例如我就在在启动脚本中添加如下语句, 它每次会先检查 flow 有没有报错, 然后才用 Node 启动项目
- "scripts":{
- "start":"flow check src && node ./server.js",
- }
7. 编写 flow 代码吧!! 但是你需要给当前文件加上 //@flow, 如果不加, 那么 flowcheck 将不做检查
- //@flow
- functionflow1(x:number){
- console.log(x);
- }
- //flow 函数
- flow1(2);
- // 普通函数
- functioncommon(a){
- console.log(a);
- }
- common(1);
运行示例
运行 flow check src 检测 src 下的执行情况
类型匹配, 无错误
类型不匹配, 报错(要求数字但传入了字符串)
Prettier
prettier 的意思是漂亮的, 但其实我觉得,"美化代码" 并不是它的核心功能, 它的核心功能是 "统一代码规范"(当然了, 是用漂亮的规范去统一哈哈). 长久以来, 团队建设的一个重点要求就是 "让几十个人写的代码看上去是一个人写的". 倘若如此, 团队协作, 代码维护能力便大大增强. Prettier 是完成这一丰功伟绩的功臣.
Prettier 是用来规范代码风格的, 一些 IDE 比如 VScode 可以给我们提供代码格式化的功能, 但是这种功能仍然有限. Prettier 则提供了相当完善的代码风格规范.
试看 --
A: 我就喜欢这样写!!
import {A,B,C,D,E} from'lib'
B: 我建议啊, 应该这样写
- import{
- A,
- B,
- C,
- D,
- E
- } from 'lib'
A: 你写的不够大气!
B: 你写的不够简洁!
(互怼时刻即将开启)
Prettier 和事佬: 好了好了, 两位英雄莫相争执, 且听我的! 你们都写成我这样就得了!
A,B: 好, 那咱就这么办
如何使用 Prettier
在 VScode 上下载 Prettier 扩展插件, 最好把编辑器重启一下. 然后保存时就可以自动格式化了
根据官网上的指示进行操作, 下面这个讲的是如何从 Eslint 上集成 Prettier Integrating with Linters . Prettier
其实一般情况下, 有 VScode 的 Prettier 插件就足够指导开发了, 如果你想一次性把全部 JS/JSX 文件全部格式化一遍, 可以这样, 在根目录下运行:
yarn prettier --write './src/**/*.js' './src/**/*.jsx'
运行示例
右边是格式化后的
ESlint
ESlint 这种和我们朝夕相处的伙伴就不必过多解释了吧, 它的作用是做一些静态检查, 对于一些可能在 JS 运行时候才会报的错误立即检测出来.
ESlint 的使用
在 VScode 上下载 Eslint 扩展插件, 最好把编辑器重启一下
设置
Eslint
这个
VScode
扩展插件的 AutoFix 功能, 如图所示
在项目下安装 eslint 命令行并进行初始化
3.1 运行 NPM init: 先初始化下 NPM 空间
3.2 运行 NPM i eslint, 安装 eslint
3.3 运行 eslint --init: 初始化 eslint
当你敲出 init 后, eslint 的命令行会自动询问你一大堆选择题, 而你只要通过箭头选择选项并回车就好了, 很方便啊!
这些问题包括:
Q1. 你想如何使用 eslint?1. 检查语法 2. 检查语法并且发现问题 3. 检查语法, 发现问题并强制约定代码风格
Q2. 你的项目使用的模块化方式? 1.CommonJS 2.Import/export 3.None of these
Q3. 你的环境? 1.Node 2. 浏览器
Q4. 你使用到的框架? 1.React 2.vue 3. None of these
Q5. 你的项目使用 TypeScript? 1.Y 2.N
(爽! 妈妈再也不用担心我的配置了)
你可能会问: 哎呀! 我不小心搞错了选项!, 那我要重新来一次吗?
不用的, 因为其实上面的选择只是帮助生成配置文件而已, 你要改随时改配置文件就可以了呀.
我们来看下面的一份配置文件
- {
- "env":{
- "browser":true,
- "es6":true
- },
- "extends":[
- "eslint:recommended",
- "plugin:@typescript-eslint/eslint-recommended"
- ],
- "globals":{
- "Atomics":"readonly",
- "SharedArrayBuffer":"readonly"
- },
- "parser":"@typescript-eslint/parser",
- "parserOptions":{
- "ecmaVersion":2018,
- "sourceType":"module"
- },
- "plugins":["@typescript-eslint"],
- "rules":{
- "semi": ["error","always"],
- "quotes":["error","double"]
- }
- }
eslint 真棒, 让我们看看这些配置选项都是怎么搞的吧
1.env 配置项
常见的可配置的有
- "env":{
- "browser":true,// 浏览器环境
- "node":true,//Node 环境
- "es6":true,//es6 语法
- "commonjs":true,//commonjs
- "worker":true//webwork 相关语法
- },
2.globals 配置项
它配的是全局变量, 一般情况下, 按照 eslint 的规则, 直接使用全局变量是会报错的, globals 配置项帮你避免了这一点
- "globals":{
- "Atomics":"readonly",
- "SharedArrayBuffer":"readonly"
- },
3.parser 配置项
可以配置解析器, 默认是用的 typescript 的解析器, 比如我们项目中就改成了 babel-parser
- "parser": "@typescript-eslint/parser",
- 4.rules
配置具体的检查细节, 比如下面这条配置直接干了 no-console, 如果使用 console.log 会报警告. 如图所示
- "rules":{
- "no-console":1
- }
每个项目后面可以跟 0,1,2 三种数字
不报错, 不警告
: 警告但不报错
报错
5.extends
你可能会问了, 哎呀!! 这么多 rules 我还怎么配啊, 这样 eslint 配置文件连起来都可以绕 VScode 两圈了!
不要担心!! 我们有 extends 配置项这个好东西, 它提供的继承功能直接集成了一些默认的配置, 如下
- "extends":[
- "eslint:recommended",
- "plugin:@typescript-eslint/eslint-recommended"
- ]
- 6.plugins
加各种插件, 比如你想增加 React 的检查怎么办?
你需要安装 eslint-plugin-react 这个插件
然后在配置中增加以下内容
"plugins":["react"]
就 OK 了
运行示例
备注: 官方推荐使用局部 eslint 而非全局 eslint
ESLint was installed locally. We recommend using this local copy instead of your globally-installed copy
来源: https://www.cnblogs.com/penghuwan/p/11479627.html