Vue Conf2022：Vue 项目配置：最佳实践与个人偏见 - 蒋豪群

初看以为是讲 webpack 或者 vite 工具的配置，看下来发现是从脚手架、工程化的角度讲各类工具的使用，对于开发项目的帮助性可能并不大，但是可以宏观认识前端构建工具这个生态系统。

嘉宾：蒋豪群，负责维护vue 构建相关的工具链，包括脚手架工具 @vue/cli 和 create-vue

主题：Vue 项目配置：最佳实践与个人偏见（PPT）

脚手架的变化

1. @vue/cli 项目变为维护模式：不再增加新功能，只做 bug 修复和重要的安全更新。
2. 发布了新一代的脚手架工具 create-vue 和 create-vite。

npm create vue@3
​
npm create vite@latest

两者区别：前者专注于 vue 项目的创建，后者集合了其他框架。

1. create-vue/create-vite 脚手架都是基于 vite 作为开发和构建工具。

转变的原因

@vue/cli 脚手架为了尽可能提供大而全的功能，内部维护了太多东西。

1. 复杂的模板逻辑耦合

例如 router 插件的模板，有大量的逻辑判断：

新脚手架中不再考虑强逻辑的模板，只执行简单的复制粘贴操作，将脚手架中的代码直接复制到用户项目中，拿来即用。

1. 过多的依赖、不一致的更新节奏

过去将创建项目和运行项目，这两个功能需求放到一个包中维护，以至于脚手架中的依赖过多，造成更新频率不一致。

1. 上面两点，造成脚手架升级脚本难写、适配难、难以面面俱到

现阶段只有推翻重来，才能彻底解决上述问题。

目前的解决方案

1. 「小而美」的独立脚手架项目：create-vue / create-vite / degit

放弃「大而全」的模式，不要试图用一个脚手架解决所有问题。现在使用 create-vite 创建比较精简的 vite 项目，使用 create-vue 创建功能稍微多一些的，能够保持和之前 @vue/cli 核心插件功能类似的项目。还可以使用 degit 从 GitHub 上拉取项目作为模板来使用 。这样的脚手架工具功能更独立，更容易维护。

1. 脚手架升级方案：模板快照 + git diff

create-vue-templates 仓库存储了所有选项可能组合出的所有的项目的模板。将其拉取到本地，使用 git log 命令，加上一个时间节点，查看某个模板至今变化的哪些内容，从而决定自己的项目中需要更新哪些内容。

git clone https://github.com/vuejs/create-vue-templates.git
cd create-vue-templates
git log --since="2022.08.10" -p typescript-jsx-vitest

配置文件的管理

现状

工具的配置文件越来越分散，为了增强用户对功能的自主控制，很多配置文件不再是单纯的 .json 文件，而是采用了 .js，.ts。

如果此时再选择将这些配置文件进行封装和隐藏，复杂度会成倍提升。开发者也难以进行自主管理。

很多工具完全不支持封装，如果将配置文件移动了目录，工具可能就找不到它而不能生效。

个人意见

仍然保持现状，不对配置文件进行封装和隐藏。

构建工具考虑的是如何更容易上手，而不是让项目变得更美观。

File Nesting Config

VS Code 有一个 File Nesting Config 功能，可以将一类配置文件放到一个配置文件中展示，在感官上可以让项目变得更美观。

Dev Server 端口

常见开发端口

3000、5000、8000、8080

存在的问题：

• 常用端口冲突概率更高，冲突后：

  1. 实际使用的端口号不确定，影响其他工具整合
  2. 稍复杂的网络环境下，会出现难以察觉的错误

Vite：Leet-speak

Vite 没有考虑使用上面这些常用的端口号，而是从 Leet-speak 中找灵感。

Leet-speak，黑客语，在旧时代的 BBS 中很常见，用数字或符号代替单词中的字母。例如:

• tombkeeper => t0mbkeeper
• ThisIsMyPassword => 7hIsisMYpA22W0RD

VITE 变形后就是 5173。 5173 既不常见，不会和其他端口产生冲突，也具有 VITE 的品牌特色。

依赖管理：npm / yarn / pnpm

现状

NPM 虽然是官方的包管理工具，但是在新特性的支持上不是很上心，在性能上也远远不如 Pnpm 和 Yarn。

• 性能：pnpm ≈ yarn > npm
• 功能对比：pnpm ≈ yarn > npm

在一些项目中可能会遇到需要修改第三方依赖的源码的场景，Pnpm 和 Yarn 内置了 patch 命令，而 Npm 需要安装第三方的 patch-package 工具。

Pnpm 和 Yarn 所管理的项目更加严格，默认均不允许使用 幻影依赖。所有依赖所用到的同级依赖都需要显式在 package.json 中写出，而不能”蹭依赖“。

过去 Pnpm 和 Yarn 存在兼容性问题。今年 Yarn 发布了 @yarnpkg/extensions ，用来解决常见的包的“蹭依赖“的问题，还有 package.json 中写错的问题。

Pnpm 也共享了这个包。所以今后在使用 Pnpm 和 Yarn 时。对于常用的一些依赖上基本不存在问题。

个人意见

Pnpm 和 Yarn 都优于 Npm，Pnpm 略优于 Yarn，因为 Yarn PnP 偶尔还是会存在不兼容 。

代码质量管理：Linter

现状

现在提到 Linter 工具，基本上就是在说 ESLint 。ESLint 周下载量大约 3000 万，月下载量1.2亿。

虽然 ESLint 使用如此之广，但是在使用时有一个很重要的用户体验问题，就是 Flat Config，如何在项目中使用共享的配置，而无需去安装它的插件，以及它的依赖的依赖。这个问题从 2020 年提出，到现在才进入第二阶段的收尾阶段，距离正式开放供用户使用尚有一段不确定的时间。

完全重写？

ESLint 2013年发布，发展近10年，生态群很壮大，用户量也很庞大。但是仍然一些问题，比如性能较差，并不能原生支持 TypeScript，需要借助第三方插件。

Flat Config 在尚未解决的情况下，ESLint 又提出了完全重写的计划。但这也需要漫长的等待。

个人意见

在提高 ESLint 的易用性方面，eslint-patch 属于黑魔法，只能作为临时方案。从今年的 ESLint 的发展来看，这个临时方案将作为长期方案来使用。所以现在 create-vue 手脚架会使用 eslint-patch 放到配置文件中，其他的一些共享配置，也依赖了 eslint-patch。

TypeScript 支持

ESLint 对 TypeScript 的支持有点堪忧。比如：

对 TS 配置文件中的项目引用的支持尚未实现：

对 Vue 的第一方的支持尚未实现：

个人意见

经过长时间的挣扎和研究后，勉强找到了一个当前可接受的配置：

如果想要用 ESLint 检查类型相关的问题，则在 .vue 文件中，最好只用 <script lang="ts"> 和 <script setup lang="ts">，不写纯 JS，则可以有较为完整的 TypeScript-ESLint 体验。

代码规范：Formatter

现状

目前最流行的 Airbnb 样式规范仍然是作为 ESLint 配置发布。但是，ESLint 自 2020 年起冻结了样式规则的新增，只做 bug 修复和 JS 新语法的支持。

Prettier 则是更活跃的代码格式化工具，而且执行结果相比 ESLint 更一致，可以和 ESLint 代码校验并行运行，性能更佳。

个人意见

• 样式规则没必要在编辑器 / IDE 里展示
• 做代码格式化，使用 Prettier，并且抛弃 eslint-plugin-prettier，即不要把 Prettier 作为 ESLint 的一部分去使用
• 后续 create-vue 脚手架生成的项目也会遵循这一点
• 关注 Rome（使用 Rust 实现、性能更好、体积更小、功能尚不全）

总结

脚手架

• 最佳实践：如无必要，避免大而全

配置文件管理

• 个人意见：在编辑器 / IDE 里隐藏，不过度封装工具

依赖管理

• 最佳实践：多考虑 npm 官方 CLI 以外的选择
• 个人意见：pnpm > yarn > npm

Linter

• 最佳实践：目前不存在；尽最大努力发挥工具价值即可

Formatter

• 最佳实践：停止混用 ESLint 和 Prettier
• 个人意见：建议使用 Prettier