背景交待

NJ 專案啟動初期，團隊技術棧主要是基於 Vue，技術選擇上就選擇了類 Vue 的 wepy。迭代幾個版本後 mpvue 出來了，簡單調研了下，準備基於 mpvue-simple 開發部分頁面，如果可行再慢慢切換其它頁面，嘗試後遇到一些問題，就暫時擱置了，還是沿用的 wepy 繼續開發。

Taro 初現

在不久之後 Taro 橫空出世，按照團隊的情況簡單對比了一下 wepy、mpvue、taro、原生元件開發。
LB 專案初期的情況是有一部分 wepy 沉澱，但是基本可以擺脫歷史包袱，重新啟動新業務專案，對於專案本身僅僅是一個活動小程式專案，不會做多端情況的考慮，在技術選擇上因為各個技術方案基本解決的問題是多端開發以及在開發過程的舒適度上的提升。對於團隊目前的情況來看，在幾個小夥伴一起討論後，還是基於 wepy 的方案來開發。

如何遷移 Taro 到 Wepy

NJ 專案本身還是基於 wepy，在迭代功能的時候，產品提出要做一個活動頁面，這個活動可能在商城小程式中也會使用到，然後 NJ 繼續迭代功能，需要考慮的是怎麼複用商城專案組開發好的活動頁面（商城專案基於 taro）。

• 跳轉到商城小程式參加活動 [pass]
• 拷貝活動頁面編譯後的檔案到 wepy 中直接使用 [cool]

如圖，上述檔案以及不需要的頁面均可以直接刪除，然後配置路由到 wepy project 的 app.json 。實際可能也有一些父級邏輯放置在 app.js 中，這個看自己的業務情況來定，我們專案還引入來 dva ，在 wepy 的 app.js 中增加來一個處理 dva 的檔案。這個遷移過程總體來說簡單容易很多，暫時不做過多描述。

如何遷移 Wepy 到 Taro

為來更為簡單的遷移，這中間寫了一個外掛來處理公共業務，對於業務邏輯可以在回撥中單獨處理，具體可以參考 wepy-plugin-migratetotaro

NJ 專案經過長期迭代在線上穩定執行。同時另外一條業務線是基於 Taro 開發，也在瘋狂開發迭代中。起因一次活動，XX 專案開發活動內容，NJ 專案正常需求開發，但是開發上線時需要複用 XX 專案開發好的活動頁面。

由於 Wepy2 目前仍處於 alpha ，1.7.x 在開發中也遇見了不少的問題。問題雖然最終都能解決，而且作者很好溝通，諮詢過幾次問題也都能耐心指導解答，筆芯感謝。
再說專案實際情況，在遷移後要保證脫離 Taro 相關專案 Wepy 獨立編譯能夠正常執行。

目錄結構約定

- Taro
    - src
    - Wepy
        - src

程式碼管理在 taro project 以子模組的形式管理 wepy project

git submodules

# 新增子模組專案
> git submodule add <taro project url>

# 初始化本地 .gitmodules 檔案
> git submodule init

# 同步遠端 submodule 原始碼
> git submodule update

.gitmodules 示例

[submodule <submodule_name>]
    path = <local_directory>
    url = <remote_url>
    branch = <remote_update_branch_name>

遷移過程

預設配置 wepy 編譯後的目錄（這裡建議配置到 taro 編譯目錄同級目錄下的子目錄。下文均以 Taro 編譯目錄 dist 為例，wepy 編譯到 dist/wepy 目錄下）

• 編譯目標路徑配置 wepy.config.js target
• 安裝外掛 wepy-plugin-migratetotaro （待開發整理髮布）
  • 載入機制 require('app.js') $instance （BASE）
  • 頁面自動配置所有，可以手動配置需要引入的 pages，但是編譯還是會編譯所有的，編譯過程不可控。暫時部分頁面引入控制略有問題，這裡建議開發過程中以頁面為維度來管理頁面資源，編譯後不需要的頁面可以手動刪除。
  • 路由處理 頁面路徑配置按照編譯路徑最後一級資料夾自動更新引入路徑中的 pages 的跳轉路徑 （BASE）
  • 所有路徑新增到子模組路由中或者主模組中 路由配置兩種模式，pages 模式 和 subPackages/pages 模式。對應的配置位置不一致，這一點由外掛編譯處理。
  • taro 元件在 wepy 中使用，在配置中新增 needComponents 配置需要使用元件的元件和頁面。

遷移過程中問題分析

① annot read property '$pages' of undefined

// 頁面初始化的時候 $createPage 中 this.$instance 不存在
if (typeof pagePath === "string") {
  this.$instance.$pages["/" + pagePath] = page;
}

// this.$instance 來源於 $createApp
let app = new appClass();

if (!this.$instance) {
  app.$init(this, appConfig);
  this.$instance = app;
  this.$appConfig = appConfig;
}

// appClass 來源於引數 對應 app.wpy
// 如果頁面要單獨執行必須載入一下 app.wpy 但是外掛處理的是編譯後的檔案，這裡只能在每個頁面 page 中單獨加入 require(wepy/app.js)

② 資源引用，建議圖片視訊等資源使用相對路徑引用，如果專案已有絕對資源路徑可以通過外掛回撥手動替換處理

③ Taro 元件共享，見後續 taro 元件共享使用方法

如何在 wepy 中使用 taro 寫的元件

這種略待程式碼侵入的感覺，可以使用環境變數來處理，只是使用遷移編譯時才生效外掛的引入。我們使用外掛引入這種是在自定義底部 tabbar 後有一個頁面需要。

• wepy page 中引入 taro 專案中的 demo 元件

  config = {
      ...
  
      usingComponents: {
          'demo': '/components/demo/index'
      }
  
      ...
  }

• template 中使用元件

  ...
  
  <demo compid="demo"></demo>
  
  ...

• 父頁面向子元件傳遞引數（配合外掛配置 needComponents 使用，如果原生小程式或者其它框架需要使用 taro 元件可以使用類似方案）

  // 按照實際情況修改 props 和 compId
  taro.propsManager.set(
    {
      ...props
    },
    compId
  );

思索

wepy taro 解決的問題是什麼？對於我而言。
一部分是追求與團隊當前技術棧相契合的類似方案。
一部分是多端需求（最新的這個小程式是多個產品的資料整合，其中之前一個產品是 H5 對外可能微信小程式不是合適的選擇，一個是小程式，如果統一到一起，後續小程式部分頁面可能也會直接轉 H5，後續還可能資料要整合到已有 APP，如此轉 RN 等也是未來的需求），這一塊是為以後做的考慮，如若不然還是原生的來的自然。
這中間更多的應該是思考，我們其實只是針對當前的產品選擇一個適合自己的技術方案，不抱著某一種方案自始自終，也不抵觸技術的更新，更多的還是需要在這業務堆積過程中不斷沉澱出一些東西，然後不斷更新自己的知識倉庫，這個才是接下來自己要堅持完善的部分。

參考資料

wepy-plugin-migratetotaro
這是一個不相關的參考資料，可以微信掃碼瀏覽一下就