{
    "baseUrl": "./",                             
    "paths": {
      "@utils/*": [
        "src/utils/*"
      ],
      "@config/*": [
        "src/config/*"
      ],
    }
}

配置完之后，使用如下方式引用a.ts模塊：

import A from '@utils/a';

發(fā)現(xiàn)我的vscode編輯器已經(jīng)能識別這個路徑了，當我按下ctrl點擊路徑的時候，也自動跳轉(zhuǎn)到了a.ts文件。在贊嘆自己純熟的技術(shù)之余，把所有的深層次路徑都換成了如上寫法，自信回頭運行npm run start:

一臉懵逼。查看bin目錄編譯后的js文件，發(fā)現(xiàn)typescript根本沒有按照我的配置，在編譯過程中把這個路徑給優(yōu)化掉。還是require('@utils/a'):

typescript不會對別名進行處理

在搗鼓了很久確定我的tsconfig配置沒有問題后，我無奈又進行了百度，發(fā)現(xiàn)typescript根本不會對別名進行處理，只能借助第三方編譯工具，例如babel，webpack。

但是我一個簡單的nodejs項目，一種編譯器足矣，我為什么需要再去使用上述編譯器？于是另一個解決方案（chao ji da ken）誕生了：

https://github.com/dividab/tsconfig-paths

另一個坑

對，就是tsconfig-paths,這個工具，我進入其github首頁，發(fā)現(xiàn)有1k左右的星星?？戳艘幌虏寮榻B，發(fā)現(xiàn)正是為了解決這個問題。使用說明也很簡單，引用官方文檔，就一句話：

哇，只要通過-r指令添加一個預(yù)處理，再運行編譯后的模塊就可以解決我的問題？興沖沖的我立即npm i --save 操作一波，發(fā)現(xiàn)還是出現(xiàn)如下問題：

這次確定是是走了他的預(yù)處理了。為什么還是不生效？？？翻看其文檔，也找不到任何有用的信息。到這里，大多數(shù)小伙伴估計都放棄了，但是今晚耗上了，一個別名問題居然拖了我這么長時間，于是我開始了源碼調(diào)試，找一下到底是什么原因。

調(diào)試tsconfig-paths

配置vscode調(diào)試器，添加運行參數(shù)：

 {
       "type": "pwa-node",
        "request": "launch",
        "name": "Launch Program",
        "skipFiles": [
            "<node_internals>/**"
        ],
        "runtimeArgs": [
            "-r",
            "${workspaceFolder}/node_modules/tsconfig-paths/register"
          ],
        "program": "${workspaceFolder}\\bin\\index.js"
  }

調(diào)試源碼，發(fā)現(xiàn)其核心功能就是讀取tsconfig文件，獲取paths（別名）映射，覆寫path._resolveFilename,匹配映射，解析獲取真正的模塊。嗯，倒是不復(fù)雜

我在這里加了個條件斷點，找到了我的utils/common的模塊請求，發(fā)現(xiàn)found為空…問題就出在這里了。于是進一步查找。發(fā)現(xiàn)其匹配規(guī)則沒問題，只是匹配到之后，尋找模塊時使用的路徑居然是原始tsconfig中配置的src…

這也太不智能了，你好歹讀一下tsconfig里的outDir屬性吧!

現(xiàn)在沒辦法了，為了適配他的代碼，只能修改tsconfig的paths配置如下：

{
    "baseUrl": "./",                             
    "paths": {
      "@utils/*": [
        "src/utils/*",
        "bin/utils/*"
      ],
      "@config/*": [
        "src/config/*",
        "bin/config/*"
      ],
    }
}

這樣他拼接的時候就能找到我的模塊了，問題終于解決！