• Vite + Vue3 实现前端项目工程化


    通过官方脚手架初始化项目

    第一种方式,这是使用vite命令创建,这种方式除了可以创建vue项目,还可以创建其他类型的项目,比如react项目

    npm init vite@latest

    第二种方式,这种方式是vite专门为vue做的配置,这种方式创建的项目在创建时会提示是否需要安装各种插件配置

    npm init vue@latest

    第三种方式,直接快速通过参数生成

    npm init vite@latest project-engineer --template vue-ts

    pnpm

    pnpm create vite my-vue-app -- --template vue

    定制化 plugins

    @vitejs/plugin-vue-jsx

    提供 Vue 3 JSX & TSX 支持(通过 专用的 Babel 转换插件)。

    安装

    npm i -D @vitejs/plugin-vue-jsx

    配置 vite.config.ts

    1. import { defineConfig } from 'vite'
    2. import vueJsx from '@vitejs/plugin-vue-jsx'
    3. export default defineConfig({
    4. plugins: [
    5. vueJsx({
    6. // options 参数将传给 @vue/babel-plugin-jsx
    7. }),
    8. ],
    9. })

    rollup-plugin-visualizer

    可视化并分析构建包,查看哪些模块占用空间大小,以此来优化构建包的大小。这是一个 Rollup 的 plugin,推荐这个也是 vite 的一个特性,vite 默认已经支持大部分的 Rollup 的 plugin,从这点来看,vite 的 plugin 库更加丰富了。

    安装

    npm i -D rollup-plugin-visualizer

    配置 vite.config.ts

    1. import { defineConfig } from 'vite'
    2. import visualizer from 'rollup-plugin-visualizer'
    3. export default defineConfig({
    4. plugins: [visualizer()],
    5. })

    vite-plugin-element-plus

    为 ElementPlus 提供按需引入能力。全量导入 ElementPlus 导致构建包的体积过大,按需引入有效的减小包的体积。此包的原理是动态将每个按需引入的组件 css 写入。

    安装

    npm i -D vite-plugin-element-plus

    配置 vite.config.ts

    1. import { defineConfig } from 'vite'
    2. import importElementPlus from 'vite-plugin-element-plus'
    3. export default defineConfig({
    4. plugins: [
    5. // @ts-ignore 此处暂时需要使用 ignore
    6. // 原因是包内部的 options 未做非必填兼容
    7. // 目前已有人提了 PR,未合并,使用可以观望下
    8. importElementPlus(),
    9. ],
    10. })

    基于 husky + lint-staged 项目规范化

    • Husky 支持所有 Git 钩子,当您提交或推送时,您可以使用 husky 来检查您的提交消息运行测试检查代码等。安装后,它会自动在仓库中的 .git/ 目录下增加相应的钩子,比如 pre-commit 钩子就会在你执行 git commit 的触发。那么我们可以在 pre-commit 中实现一些比如 lint 检查、单元测试、代码美化等操作。当然,pre-commit 阶段执行的命令当然要保证其速度不要太慢,每次 commit 都等很久也不是什么好的体验。

    • lint-staged,一个过滤出 Git 代码暂存区文件(被 git add 的文件)的工具。这个很实用,因为我们如果对整个项目的代码做一个检查,可能耗时很长,如果是老项目,要对之前的代码做一个代码规范检查并修改的话,这可能就麻烦了呀,可能导致项目改动很大。所以 lint-staged,对团队项目和开源项目来说,是一个很好的工具,它是对个人要提交的代码的一个规范和约束。

    Eslint

    eslint 用于配置代码风格、质量的校验,prettier用于代码格式的校验,lint-staged 过滤文件。

    本项目已经默认安装 eslint、prettier,如果需要单独安装,执行以下命令:

    1. # 安装 eslint
    2. npm i eslint -D
    3. # 利用 eslint 命令行工具生成基本配置
    4. npx eslint --init

    生成的 .eslintrc.cjs 文件,如下:

    1. /* eslint-env node */
    2. require('@rushstack/eslint-patch/modern-module-resolution')
    3. module.exports = {
    4. root: true,
    5. 'extends': [
    6. 'plugin:vue/vue3-essential',
    7. 'eslint:recommended',
    8. '@vue/eslint-config-typescript',
    9. '@vue/eslint-config-prettier/skip-formatting'
    10. ],
    11. parserOptions: {
    12. ecmaVersion: 'latest'
    13. }
    14. }

    做一下配置补充

    1. /* eslint-env node */
    2. require('@rushstack/eslint-patch/modern-module-resolution')
    3. module.exports = {
    4. root: true,
    5. env: {
    6. browser: true,
    7. node: true,
    8. es6: true
    9. },
    10. 'extends': [
    11. 'plugin:vue/vue3-essential',
    12. 'eslint:recommended',
    13. '@vue/eslint-config-typescript',
    14. '@vue/eslint-config-prettier/skip-formatting'
    15. ],
    16. parserOptions: {
    17. ecmaVersion: 'latest',
    18. sourceType: 'module',
    19. ecmaFeatures: {
    20. jsx: true
    21. }
    22. },
    23. plugins: ['@typescript-eslint'],
    24. rules: {}
    25. }

    这里为什么生成的配置文件名称是.eslintrc.cjs而不是.eslintrc.js?

    因为我们将项目定义为 ESM,eslint --init 会自动识别 type,并生成兼容的配置文件名称,如果我们改回 .js 结尾,再运行 eslint 将会报错。出现这个问题是 eslint 内部使用了 require() 语法读取配置。

    同样,这个问题也适用于其他功能的配置,比如后面会讲到的 Prettier、Commitlin t等,配置文件都不能以 xx.js 结尾,而要改为当前库支持的其他配置文件格式,如:.xxrc、.xxrc.json、.xxrc.yml。

    Prettier

    Prettier 如果需要单独安装,执行以下命令:

    1. # 安装 prettier
    2. npm i prettier -D

    .prettierrc.json 默认配置如下(没有这个文件的需要自行创建)

    1. {
    2. "$schema": "https://json.schemastore.org/prettierrc",
    3. "semi": false,
    4. "tabWidth": 2,
    5. "singleQuote": true,
    6. "printWidth": 100,
    7. "trailingComma": "none"
    8. }
    • semi:false 句末是否使用分号(false | true)

    • singleQuote:true 是否使用单引号代替双引号(false | true)

    • trailingComma:'none' 最后一个对象元素是否加逗号, 'none' 为不加

    • tabWidth 设置工具每一个水平缩进的空格数

    • printWidth 换行字符串阈值

    • bracketSpacing:true 对象,数组是否加空格(false | true)

    • jsxBracketSameLine:true jsx > 是否另起一行(false | true)

    • arrowParens :’always‘ (x) => {} 是否要有小括号,值为 ’always‘ 则需要

    • requirePragma:false 是否需要写文件开头的 @prettier (false | true)

    • insertPragma:false 是否需要自动在文件开头插入 @prettier

    Prettierrc & ESLint 规则冲突的解决

    eslint 用于配置代码风格、质量的校验,prettier用于代码格式的校验,lint-staged 过滤文件

    但两者在使用过程中,会因为规则不同,有出现冲突的可能性,所以需要通过插件加强两者的配合:

    • eslint-plugin-prettier 一个 ESLint 插件, 由 prettier 生态提供,用于关闭可能与 prettier 冲突的规则

    • eslint-config-prettier 使用 prettier 代替 eslint 格式化,防止 Prettier 和 ESLint 的自动格式化冲突

    安装

    npm i eslint prettier lint-staged eslint-plugin-prettier eslint-config-prettier -D

    Husky

    因为一个项目通常是团队合作,我们不能保证每个人在提交代码之前执行一遍 lint 校验, 所以需要 git hooks 来自动化校验的过程,否则禁止提交。

    1. # 安装 husky
    2. npm i husky -D
    3. # 生成 .husky 文件夹(注意:这一步操作之前,一定要执行 git init 初始化当前项目仓库,.husky 文件夹才能创建成功)
    4. npx husky-init install

    在 package.json 中添加 'prepare' 指令

    1. "scripts": {
    2. // 省略其它指令
    3. "prepare": "husky install"
    4. }

    .husky/pre-commit 文件修改如下

    1. #!/usr/bin/env sh
    2. . "$(dirname -- "$0")/_/husky.sh"
    3. npm run lint

    Commitlint

    为什么需要 Commitlint,除了在后续生成的 changelog 文件和语义发版中需要提取 commit 中的信息外,也利于其他团队开发者分析你提交的代码,所以我们要约定commit的规范。

    安装如下两个插件:

    • @commitlint/cli Commitlint 命令行工具

    • @commitlint/config-conventional 基于 Angular 的约定规范

    npm i @commitlint/config-conventional @commitlint/cli -D

    最后将 Commitlint 添加到钩子:

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

    创建 .commitlintrc,并写入配置

    1. {
    2. "extends": [
    3. "@commitlint/config-conventional"
    4. ]
    5. }

    Angular 规范说明:

    • feat:新功能

    • fix:修补 BUG

    • docs:修改文档,比如 README, CHANGELOG, CONTRIBUTE 等等

    • style:不改变代码逻辑 (仅仅修改了空格、格式缩进、逗号等等)

    • refactor:重构(既不修复错误也不添加功能)

    • perf:优化相关,比如提升性能、体验

    • test:增加测试,包括单元测试、集成测试等

    • build:构建系统或外部依赖项的更改

    • ci:自动化流程配置或脚本修改

    • chore:非 src 和 test 的修改,发布版本等

    • revert:恢复先前的提交

    1

  • 相关阅读:
    cad由于找不到mfc140u.dll怎么回事?mfc140u.dll丢失的解决方法
    Flutter快学快用03 Hello Flutter:三步法掌握 Flutter,开始你的第一个应用
    Modern C++
    HS6621Cx 一款低功耗蓝牙SoC芯片 应用于键盘、鼠标和遥控器消费类产品
    Java面向对象编程---基础篇
    Sass详解和应用
    .NET6 开源之JSON 2 SQL (JORM框架)
    SwiftUI 教程之如何在 SwiftUI 中更改 NavigationStack 背景颜色
    【C++】Floyd多源最短路算法
    ELFK日志分析系统并使用Filter对日志数据进行处理
  • 原文地址:https://blog.csdn.net/m0_38066007/article/details/133029683