10分钟带你从0到1搭建monorepo 工程化项目(二)

简介: eslint对于eslint 的配置其实我们可以如法炮制,我们项目的根目录 新建 .eslintrc 然后我们每个子项目 同样继承外部的 .eslintrc好的下面我们开始安装 eslintyarn add eslint -D -W然后我们生成eslint 的配置文件npx eslint --init由于我们的项目 是基于 React 和 ts 的 所以在选择的按照下面进行选择图片eslint-config这时候在我们的根目录 就会出现**.eslint.yml** 这个配置文件 这里你也可以选择你喜欢的配置文件格式, 个人比较喜欢YAML 这种方式env:

eslint



对于eslint 的配置其实我们可以如法炮制,我们项目的根目录 新建 .eslintrc  然后我们每个子项目 同样继承外部的 .eslintrc


好的下面我们开始安装 eslint


yarn add eslint -D -W


然后我们生成eslint 的配置文件


npx eslint --init


由于我们的项目 是基于 React 和 ts 的 所以在选择的按照下面进行选择


image.png


eslint-config


这时候在我们的根目录 就会出现**.eslint.yml** 这个配置文件 这里你也可以选择你喜欢的配置文件格式, 个人比较喜欢YAML 这种方式


env:
  browser: true
  node: true
extends:
  - plugin:react/recommended
  - eslint:recommended
  - airbnb
parser: '@typescript-eslint/parser'
parserOptions:
  ecmaFeatures:
    jsx: true
  ecmaVersion: 2020
  sourceType: module
plugins:
  - react
  - '@typescript-eslint'
  - react-hooks
rules:


然后就会出现下面这个文件我来一一解读下面每一条的配置文件


env


  1. 表示你在 eslint 想启用的环境  我们是前端嘛 所以 就是 node 和 browser,官网支持的还是比较多的


extends


单从字面上去理解就是 继承  其他的配置 可以是 文件路径 形式的 或者是 下载的插件包的  这里的话 一般npm包的 格式


是下面这样子的


eslint-config-packagename


  1. 我们在配置的时候 前面的 eslint-config 可以省略, 我这使用的是airbnb 的配置。
    或者安装的包的名字 是这样子


eslint-plugin-packagename


  1. 然后就可以 eslint-plugin 可以省略,然后就可以像下面使用


plugin:xxxx/recommended


  1. 或者 是子目录下继承根目录的 eslint 例如如下:


extends:  ../../.eslintrc


  1. 当一切准备就绪后,我们的项目目录应该大致呈如下所示的结构:


.
├── package.json
├── .eslintrc
└── packages/
    │   ├── tsconfig.json
    │   ├── .babelrc
    ├── project_1/
    │   ├── index.js
    │   ├── .eslintrc
    │   ├── .babelrc
    │   ├── tsconfig.json
    │   └── package.json
    └───project_2/
        ├── index.js
        ├── .eslintrc
        ├── .babelrc
        ├── tsconfig.json
        └── package.json


  1. parser


ESLint 默认使用Espree作为其解析器, 但是由于我们项目是 ts 文件, 所以安装


yarn add @typescript-eslint/parser


  1. 作用 就是将 TypeScript 转换成与 estree 兼容的形式,以便在ESLint中使用。eslint  也是对AST 进行操作,但是对TS 是不支持的,所以做一层转换成 js.
    parserOption
    有了解析器肯定就有解析参数


ecmaFeatures:
    jsx: true // 表示支持jsx 语法 但是React 对 ESLint 无法识别的JSX语法应用特定的语义。如果你正在使用 React 并且想要 React 语义支持,我们建议你用 eslint-plugin-react。
  ecmaVersion: 2020  // 默认的js 的版本  
  sourceType: module // esm 模式


  1. plugins

正如上面所说,在解析参数配置了支持jsx 语法, 但是 ESLint 无法识别的JSX语法应用特定的语义。如果你正在使用 React 并且想要 React 语义支持,我们建议你用 eslint-plugin-react。这就是所谓的插件 ,这里安装了  react 和 react-hooks 两个插件


yarn add eslint-plugin-react  eslint-plugin-react-hooks


  1. 然后我们就可以 plugins 进行配置了 同样可以省略 eslint-plugin

rules


rules 的定义我们一般看到的就是这样子, 具体的配置可以自己查官方列表


---
rules:
  eqeqeq: off
  curly: error
  quotes:
    - error
    - double


然后你如果安装了插件


就可以插件名/ 规则  可以对默认的插件配置 进行重写, 比如下面这样子


'react-hooks/rules-of-hooks': 2
'react-hooks/exhaustive-deps': 2


与VScode 集成


"editor.codeActionsOnSave": {
        "source.fixAll.eslint": true
  }


prettier



prettier 的出现其实为了解决代码格式的问题?这是eslint  无法做到的


Prettier中文的意思是漂亮的、美丽的,是一个流行的代码格式化的工具,我们来看如何结合ESLint来使用。首先我们需要安装三个依赖:


安装 npm 包


yarn add prettier eslint-config-prettier eslint-plugin-prettier  -D -W


  1. prettier:prettier插件的核心代码


  1. eslint-config-prettier:解决ESLint中的样式规范和prettier中样式规范的冲突,以prettier的样式规范为准,使ESLint中的样式规范自动失效


  1. eslint-plugin-prettier:将prettier作为ESLint规范来使用


然后在项目的根目录下创建.prettierrc文件:


{
    "printWidth": 120,
    "semi": false,
    "trailingComma": "all",
    "singleQuote": true,
    "arrowParens": "always"
}


接着修改.eslintrc.js文件,引入prettier:


extends:
  - plugin:react/recommended
  # - plugin:import/recommended
  - eslint:recommended
  - airbnb
  - prettier
plugins:
  - react
  - '@typescript-eslint'
  - react-hooks
  # - import
  - prettier


分别在extends 和 plugins 加入 prettier


husky和lint-staged构建代码工作流



在这之前我先简单介绍 下Husky 和 lint-staged 这两个东西 到底是干什么的??


husky


husky目前是前端工程化必备的一个工具了, husky 这个 npm 包 说白了就是在git 提交前 提供一些钩子 hooks 方便你运行一些脚本命令。下面跟着我可以实操一下


yarn add husky -D -W


第二步:在packgae.json中添加prepare脚本


{
  "scripts": {
    "prepare": "husky install"
  }
}


prepare脚本会在npm install(不带参数)之后自动执行。也就是说当我们执行npm install安装完项目依赖后会执行 husky install命令,该命令会创建.husky/目录并指定该目录为git hooks所在的目录。


第三步 添加 git hooks


npx husky add .husky/pre-commit "yarn lint-staged"


这时候在我们根目录 就会出现 .husky 的目录


image.png


husky


然后写入 pre-commit 脚本


#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
yarn lint-staged


由于我们还没有装  lint-staged , 直接运行会报错

lint-staged


yarn add lint-staged -D -W


Lint-staged  用于对 Git 暂存区中的文件执行代码检测, 然后我们同样也可以做一些操作

我们在package.json 增加如下配置


"lint-staged": {
    "*.@(js|ts|tsx)": [
      "eslint --ext .ts,.tsx,.js --fix",
      "prettier --write",
      "git add"
    ],
    "*.@(yml|yaml)": [
      "prettier --parser yaml --write"
    ],
    "*.md": [
      "prettier --parser markdown --write"
    ],
    "*.json": [
      "prettier --parser json --write"
    ]
  },


我们看下第一个,当匹配到 以 js 或者 ts 或者是tsx 结尾的文件时候, 这时候我们就可以 结合 之前 的eslint  和 prettirer 做一些操作


  1. eslint  对这些文件 检测 并自动修复


  1. 然后  使用 prettier --  write 进行自动检测


  1. 最后添加到 暂存区中


我们run 一下 看下效果:


image.png

husky 录屏


你会发现好像已经成功了, 但是最后 还是失败了,因为我在husky 还加了一个hook 用于在提交命令前 规范 commit-msg

我们输入下面命令


npx husky add .husky/commit-msg 'yarn commitlint --edit "$1"'


然后在.husky 的目录 就会出现下面这张图


image.pngcommit


由于运行了这个脚本 commitlint 这个脚本  但是我们 安装 老样子


yarn  add commitlint  @commitlint/config-conventional  @commitlint/config-lerna-scopes -D -W


**@commitlint/config-conventional **  这里会使用默认angular 团队的提交规范


@commitlint/config-lerna-scopes  由于我们是lerna  多个packages  主要是用来限制在packages 里的包 不在的 就会报错,


packages
├── api
├── app
└── web
❯ echo "build(api): change something in api's build" | commitlint
⧗   input: build(api): change something in api's build
✔   found 0 problems, 0 warnings
❯ echo "test(foo): this won't pass" | commitlint
⧗   input: test(foo): this won't pass
✖   scope must be one of [api, app, web] [scope-enum]
✖   found 1 problems, 0 warnings


foo 不属于项目中的一个包, 所以 直接 会报错。


在项目的根目录 新建:commitlint.config.js


module.exports = {
  extends: ['@commitlint/config-conventional', '@commitlint/config-lerna-scopes'],
}


这样我们提交的时候就会做到我们上面的限制, 项目代码的提交规范 还是很重要的


生成changelog



首先,聊一下什么是 CHANGELOG ,为什么需要 CHANGELOG ?它记录你项目所有的commit信息并归类版本,可以快速跳转到该条commit记录,甚至可以显示修改人信息一眼发现bug的创建者😂。它能让你方便知道项目里哪个版本做了哪些功能有哪些bug等信息。也方便排查bug,对于提交记录一目了然,不用一个一个去翻去查。


这里我们安装 这个包


yarn  add  standard-version -D -W


这里,就直接用 standard-version 来实现自动生成 CHANGELOG  了。conventional-changelog 咱们就不聊了,毕竟是它推荐咱们用 standard-version (这都是同一个团队的东西,基于conventional-changelog实现的)。


semantic-release  还有这个 进行生成


至于这两个的区别??我们看下


semantic-release 自动化整个包发布工作流程,包括:确定下一个版本号、生成发布说明和发布包。


虽然两者都基于结构化提交消息的相同基础,但标准版本采用不同的方法,为您处理版本控制、更改日志生成和 git 标记,而无需自动推送(到 GitHub)或发布(到 npm 注册表)。使用标准版本只会影响您的本地 git 存储库 - 它根本不会影响远程资源。运行标准版本后,您可以查看发布状态、纠正错误并遵循对您的代码库最有意义的发布策略。我们认为它们都是很棒的工具,如果对他们的用例有意义,我们鼓励人们使用语义发布而不是标准版本


然后我们在package.json  新增这脚本


"release": "standard-version",


为了 让我们的changeLog 看起来好看一点在项目根目录 新增 .versionrc.js


module.exports = {
  types: [
    { type: 'feat', section: '✨ Features | 新功能' },
    { type: 'fix', section: '🐛 Bug Fixes | Bug 修复' },
    { type: 'init', section: '🎉 Init | 初始化' },
    { type: 'docs', section: '✏️ Documentation | 文档' },
    { type: 'style', section: '💄 Styles | 风格' },
    { type: 'refactor', section: '♻️ Code Refactoring | 代码重构' },
    { type: 'perf', section: '⚡ Performance Improvements | 性能优化' },
    { type: 'test', section: '✅ Tests | 测试' },
    { type: 'revert', section: '⏪ Revert | 回退' },
    { type: 'build', section: '📦‍ Build System | 打包构建' },
    { type: 'chore', section: '🚀 Chore | 构建/工程依赖/工具' },
    { type: 'ci', section: '👷 Continuous Integration | CI 配置' },
  ],
}


然后在husky 新增 pre-push 脚本


npx husky add .husky/pre-commit "yarn release"


这样我们在 git push 提交代码的时候  就会自动生成changelog


image.png


changeLog

相关文章
|
15天前
|
资源调度 前端开发 测试技术
前端工程化实践:从零搭建现代化项目构建流程
【4月更文挑战第6天】本文介绍了前端工程化的概念和重要性,包括模块化、自动化、规范化和CI/CD。接着,讨论了选择合适的工具链,如包管理器、构建工具和测试框架。然后,详细阐述了如何从零开始搭建一个基于React的现代化项目构建流程,涉及初始化、代码规范、测试、CSS处理、代码分割和CI/CD配置。最后,提到了持续优化与迭代的方向,如性能优化、类型检查和微前端。通过这样的实践,开发者可以提升开发效率和代码质量,为项目长远发展奠定基础。
25 0
|
1月前
|
缓存 前端开发 JavaScript
Vite 构建流程大揭秘:快速构建前端项目的秘密武器
Vite 构建流程大揭秘:快速构建前端项目的秘密武器
|
3月前
|
自然语言处理 前端开发 测试技术
前端工程化最佳实践:项目结构、代码规范和文档管理
前端工程化最佳实践:项目结构、代码规范和文档管理
|
6月前
|
JavaScript 前端开发 关系型数据库
和chatgpt学架构01-搭建项目脚手架
和chatgpt学架构01-搭建项目脚手架
|
存储 JSON 资源调度
10分钟带你从0到1搭建monorepo 工程化项目(一)
前言 大家好,我是Fly哥, 之前写博客的仓库,还是用的原生的html 和js 也没有引入 ts , 和一些工程化的东西, 所以自己重新搭建了一套前端项目架构 基于 lerna + yarn 的 monrepo的仓库, 主要是后面会学习输出的一些东西, 整个架子先搭建起来。 2d 和 3d 公共 util 的封装 个人 npm 包的发布 (rollup) 2d react 项目 搭建(vite) 3d react 项目 搭建 (webpack) 搭建一套基于webpack 5 的cli 每个项目都有一些特定的依赖, 但是也会有一些相同的依赖。比如eslint、 babel 的一些基础配置,
10分钟带你从0到1搭建monorepo 工程化项目(一)
|
8月前
|
前端开发 JavaScript API
前端工程化和构建工具的选择
前端工程化和构建工具的选择
|
10月前
|
存储 资源调度 JavaScript
基于 Yeoman 脚手架技术构建前端项目的实践
基于 Yeoman 脚手架技术构建前端项目的实践
130 0
|
10月前
|
前端开发 JavaScript 开发者
前端工程化构建工具之Gulp
在前端工程化构建工具中,Gulp是一个非常流行的开源工具。
58 0
|
10月前
|
前端开发 JavaScript 网络安全
如何开发一个极简的前端脚手架
如何开发一个极简的前端脚手架
157 0
|
11月前
|
缓存 前端开发 JavaScript
前端工程化的学习(偏向vite构建工具)
前端工程化的学习(偏向vite构建工具) 好早就听说了vite,也早就简单的使用并了解了一点,之前在公司实习团队也正在迁移webpack的项目到vite,但我自己却一直没有深入,毕竟还是初级前端工程师,功力还欠缺很多,但最近封装了一个小组件,整个项目不使用脚手架挺难受的,到处参考别人的代码希望能找到组件开发的最佳实践,整个过程举步维艰,所以开始先从vite入手学习一下前端工程化相关的东西了...
302 0