接下來看一下核心的源碼部分，這里聲明了一個components訪問者：

// components 的遍歷器
const componentsVisitor = {
  ExportDefaultDeclaration: function (path) {
    path.traverse(traverseComponentsVisitor)
  }
}

traverseComponentsVisitor里面主要是對結(jié)構(gòu)的一個解析，最后獲取到importsMap，然后組裝成一個components對象并返回

// 解析 components
const traverseComponentsVisitor = {
  Property: function (path) {
    // 只對類型為components的進行操作
    if (path.node.key.name !== 'components') {
      return
    }
    path.stop()

    const { metadata } = path.hub.file
    const { importsMap } = getImportsMap(metadata)

    // 找到所有的 imports
    const { properties } = path.node.value
    const components = {}
    properties.forEach(p => {
      const k = p.key.name || p.key.value
      const v = p.value.name || p.value.value

      components[k] = importsMap[v]
      // Example: components = { Card: '@/components/card' } 
    })

    metadata.components = components
  }
}

對于 import Card from '@/components/card' 
component就應(yīng)該為 { Card: '@/components/card' } 
對于 import { LTabbar, LTabbrItem } from '@/components/tabbar' 
則會被解析為 { LTabbar: '@/components/tabbar', LTabbarItem: '@/components/tabbar' } 
而我們期望的顯然是 { LTabbar: '@/components/tabbar/tabbar', LTabbarItem: '@/components/tabbar/tabbar-item' }

然后我就得到這樣一個思路：

• 從path中解析出LTabbar和LTabbarItem真實的路徑，或者關(guān)聯(lián)的部分
• 找到以后替換這里的importsMap

感覺想法并沒有錯，但是我花費了大量的精力去解析path最后得出一個結(jié)論... 解析不出來?。。陂g嘗試了 ImportDeclaration 從中得到過最接近期望的一段path，
然而它是被寫在 LeadingComments 這個字段當中的，除非沒有辦法的辦法，否則就不應(yīng)該通過這個字段去進行正則匹配

既然從babel插件這條路走不通了，所以想著是否可以從其他路試試，然后就到了第二個關(guān)鍵點部分

組件的realSrc

既然在babel組件當中的importsMap不是我真正想要的依賴文件，那究竟依賴文件怎么獲取到呢？首先我再compileMPScript里面打印了一下 this.resourcePath ，得到了以下輸出

resource:  /Users/linyiheng/Code/wechat/my-project/src/App.vue
resource:  /Users/linyiheng/Code/wechat/my-project/src/pages/counter/index.vue
resource:  /Users/linyiheng/Code/wechat/my-project/src/pages/index/index.vue
resource:  /Users/linyiheng/Code/wechat/my-project/src/pages/logs/index.vue
resource:  /Users/linyiheng/Code/wechat/my-project/src/components/card.vue
resource:  /Users/linyiheng/Code/wechat/my-project/src/components/tabbar/tabbar.vue
resource:  /Users/linyiheng/Code/wechat/my-project/src/components/tabbar/tabbar-item.vu

這個其實就是文件的一個加載順序，由于LTabbar、LTabbarItem這兩個組件是在pages/index/index.vue被引入的，所以相應(yīng)的解析操作會被放在這里進行，
但是從babel組件無法得到這兩個組件的realSrc，那么是否可以從最后加載進來的兩個vue組件著手考慮呢，這個resourcePath顯然就是我們想要的realSrc

簡單的給traverseComponentsVisitor加上這樣的一個代碼段

// traverseComponentsVisitor
if (path.node.key.name === 'component') {
  path.stop()
  const k = path.node.value.value
  const components = {}
  const { metadata } = path.hub.file
  components[k] = ''
  metadata.components = components
  return
}

然后稍微改造一下this.resolve的處理

// 如果originComponents[k]不存在的情況下，則使用當前的resourcePath
this.resolve(this.context, originComponents[k] || this.resourcePath, (err,

感覺一切就緒了，嘗試發(fā)現(xiàn)仍然是不行的，雖然我的確得到了組件的realSrc，但是對于pages/index/index.vue而言，已經(jīng)完成了wxml模板的輸出了，
而后面進行的主體是components/tabbar/tabbar.vue和components/tabbar/tabbar-item.vue，顯然這個時候是無法輸出wxml的。看一下生成Wxml的核心代碼

function createWxml (emitWarning, emitError, emitFile, resourcePath, rootComponent, compiled, html) {
  const { pageType, moduleId, components, src } = getFileInfo(resourcePath) || {}
  // 這兒一個黑魔法，和 webpack 約定的規(guī)范寫法有點偏差！
  if (!pageType || (components && !components.isCompleted)) {
    return setTimeout(createWxml, 20, ...arguments)
  }

  let wxmlContent = ''
  let wxmlSrc = ''

  if (rootComponent) {
    const componentName = getCompNameBySrc(rootComponent)
    wxmlContent = genPageWxml(componentName)
    wxmlSrc = src
  } else {
    // TODO, 這兒傳 options 進去
    // {
    //   components: {
    //     'com-a': { src: '../../components/comA$hash', name: 'comA$hash' }
    //   },
    //   pageType: 'component',
    //   name: 'comA$hash',
    //   moduleId: 'moduleId'
    // }
    // 以resourcePath為key值，從cache里面獲取到組件名，組件名+hash形式
    const name = getCompNameBySrc(resourcePath)
    const options = { components, pageType, name, moduleId }
    // 將所有的配置相關(guān)傳入并生成Wxml Content
    wxmlContent = genComponentWxml(compiled, options, emitFile, emitError, emitWarning)
    // wxml的路徑
    wxmlSrc = `components/${name}`
  }
  // 上拋
  emitFile(`${wxmlSrc}.wxml`, wxmlContent)
}

這部分代碼主要的工作其實就是根據(jù)之前獲取的組件 & 組件路徑相關(guān)信息，通過genComponentWxml生成對應(yīng)的wxml，但是由于沒辦法一次性拿到realSrc，所以我覺得這里的代碼存在著一些小問題，理想的效果應(yīng)該是完成所有的components解析以后再進行wxml的生成，那么這件問題就迎刃而解了。其實作者用嘗試通過components.isCompleted來實現(xiàn)異步加載的問題，但是除非是把所有的compileMPScript給包含在一個Promise里面，否則的話感覺這步操作似乎沒有起到作用。（也有可能是我理解不到位）

總結(jié)

雖然這個需求并不是優(yōu)先級很高的一個需求，但是從這個需求出發(fā)看源碼，的確是有發(fā)現(xiàn)源碼中的一些瑕疵（當然換我我還寫不出來...所以還是得支持一下大佬的），順帶也了解了一下Babel插件實現(xiàn)的原理，了解了loader大概的一個實現(xiàn)原理，所以還是收獲頗豐的。

經(jīng)過了那么久時間的嘗試我還是沒有解決這個問題，說實話我是心有不甘的，我把這次經(jīng)驗整理出來也希望大家能夠給我提供一些思路，或是如何解析babel插件，或是如何實現(xiàn)wxml的統(tǒng)一解析，或是還有其他的解決方案。最后希望mpvue能夠越來越棒