背景

純nodejs環(huán)境，直接使用tsc編譯nodejs。源碼目錄是src，編譯輸出目錄為bin。代碼結(jié)構(gòu)如下：

• src
  • utils
    • a.ts
    • b.ts
  • config
  • …
• bin
• tsconfig.json

在其他深層次目錄引用utils或者config下的文件時(shí)，總是要寫一長(zhǎng)串的'../../../../'，還需要數(shù)數(shù)。這顯然是不能接受的。用過(guò)webpack開(kāi)發(fā)的小伙伴們，想想別名功能，typescript這種成熟框架不可能沒(méi)有。于是百度一波，得到如下配置：

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

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

import A from '@utils/a';

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

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

typescript不會(huì)對(duì)別名進(jìn)行處理

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

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

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

另一個(gè)坑

對(duì)，就是tsconfig-paths,這個(gè)工具，我進(jìn)入其github首頁(yè)，發(fā)現(xiàn)有1k左右的星星。看了一下插件介紹，發(fā)現(xiàn)正是為了解決這個(gè)問(wèn)題。使用說(shuō)明也很簡(jiǎn)單，引用官方文檔，就一句話：

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

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

調(diào)試tsconfig-paths

配置vscode調(diào)試器，添加運(yùn)行參數(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ù)雜

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

我的運(yùn)行目錄明明在bin目錄！

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

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

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

這樣他拼接的時(shí)候就能找到我的模塊了，問(wèn)題終于解決！

總結(jié)

到此這篇關(guān)于typescript在node.js下使用別名(paths)無(wú)效問(wèn)題詳解的文章就介紹到這了,更多相關(guān)typescript在node.js使用別名無(wú)效內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論