Vue2和Vue3子系统

上一篇：Vue2和Vue3创建应用对比

在了解vue3的众多优势，以及熟悉了vue2和vue3在创建应用的不同后；常见的一个场景就是vue2升级升级vue3；有一种很稳妥的方式，就是将新功能和重大改造通过子系统实现，逐步进行迁移和切换；这样既保持了系统的问题，也能逐步使用最新的技术给系统带来更高效的开发和简单的维护。

 

1.子系统结构

  main-project/

  ├── package.json           # 根项目 (Vue 2, vue-cli-service, webpack 4)

  ├── src/                         # 根项目 (Vue 2)

  ├── node_modules/        # 根项目依赖

  │

  └── packages/

      └── sub-project/            # 新签约室 (Vue 3, Vite 5, TypeScript)

          ├── package.json       # 完全独立的依赖体系

          └── src/                       # 独立的子项目

            └── node_modules/    # 独立的 node_modules

 

2.子系统配置

main-project和sub-project两者完全独立，没有互相 import，各自有独立的 node_modules；为了统一编译和打包，方便开发和发布，需要引入“npm-run-all”实现串行构建。

sub-project/package.json关键配置：

{

  ...,

  "scripts": {

    "dev": "vite",

    "build:test": "vite build --mode test",

    "build:prod": "vite build",

    "lint": "eslint",

    "lint:fix": "eslint --fix"

  },

  ...

}

main-project/package.json关键配置：

  {

  ...,

  "scripts": {

    "dev": "vue-cli-service serve",

    "build:test": "run-s build:test:*",

    "build:prod": "run-s build:prod:*",

    "build:test:main": "vue-cli-service build --mode test",

    "build:prod:main": "vue-cli-service build",

    "build:test:sub-project": "npm run build:test --prefix packages/sub-project",

    "build:prod:sub-project": "npm run build:prod --prefix packages/sub-project",

    "lint": "vue-cli-service lint",

    "lint:eslint": "eslint --fix --ext .js,.ts,.vue ./src",

    "prepare": "run-s prepare:*",

    "prepare:husky": "husky install",

    "prepare:sub-project": "npm install --prefix packages/sub-project"

  },

  "devDependencies": {

    "npm-run-all": "^4.1.5",

    ...

  },

  ...

}

 

3.子系统升级方案

此方式本质上还是两个独立的应用，只是放在一个项目中方便开发和管理；由于是独立的，所以编译打包也会相对较慢，以及有共同的组件也无法引用。

在此方式的基础上，还有3个阶段可供了解和升级，可根据不同的场景选择。

 

 阶段 0（当前）
───────────────────────────────────────────────
npm install  →  prepare 钩子装 sign 依赖 
npm run build:test  →  run-s 串行构建
版本管理：无 
适合：2 个包，互不依赖，不需要发包
───────────────────────────────────────────────
           │ 包间需要共享代码时
           ▼
  阶段 1：加 pnpm workspace
───────────────────────────────────────────────
pnpm install  →  一次装完所有包
包间可直接 import 
公共依赖去重，省磁盘
改动：加 pnpm-workspace.yaml，换 packageManager
───────────────────────────────────────────────
           │ 包 >= 3 个，构建变慢
           ▼
  阶段 2：加 Turborepo

───────────────────────────────────────────────
pnpm turbo build  →  自动并行 + 增量缓存
改一行代码只构建相关包 
CI 从几分钟 → 几秒 
改动：加 turbo.json，根 package.json 加 turbo
───────────────────────────────────────────────
           │ 包要对外发布
           ▼
  阶段 3：加 Changeset
───────────────────────────────────────────────
pnpm changeset  →  记录变更 
pnpm changeset version  →  升版本 + CHANGELOG
pnpm changeset publish  →  按顺序发布
改动：加 @changesets/cli，配 .changeset 
────────────────────────────────────────────────

总结：
当仅升级需要2个包，且之间互不依赖，现有方案够用。 如果接下来要抽 packages/shared 公共层，先上 pnpm workspace，一次到位。

Turborepo 和 Changeset 等方案可等出现痛点时再加。