背景：

我們需要將React開發的應用部署到一個活動搭建平臺上，這意味我們只需要上傳源碼，沒有搭建服務器的環節，沒有配置Nginx的環節。具體步驟就是在該平臺新建一個活動，然后將自己的源碼傳到這個活動下，然后打開這個活動提供的地址，然后就能夠看到頁面。

我們上傳的js文件main.js會得到一個js/main.js的路徑，然后將這個路徑放到html的script標簽的src屬性上即可。main.css同理會得到一個css/main.css的路徑，然后放到link標簽的href屬性上即可。

這些做完查看頁面的時候我們會發現script標簽的src屬性被替換成了//xxx.com/xxx/xxx/main.js?t=xxx這種形式。同樣css也被換成了//xxx.com/xxx/xxx/main.css?t=xxx。需要注意的是這個路徑中并沒有js/和css/這種東西。

注：另外上傳的html文件存儲的位置和JS/CSS并不在一起。

現在我們知道上傳的資源除了HTML文件會被存在//xxx.com/xxx/xxx/目錄下。

當我們用createReactApp創建的腳手架打包React應用的時候可以修改publicPath為//xxx.com/xxx/xxx/這樣打出來的包中HTML文件的script標簽和link標簽的對應屬性就絕對路徑（絕對路徑并不會被自動替換）。并且是正確的絕對路徑。

到目前為止玩耍的很開心。

有一天的一個時間節點之后，發現傳上去的應用訪問不通，報錯了，JS和CSS文件找不到。排查之后發現活動平臺升級之后，將存儲JS和CSS這種靜態資源的域名換掉了。而我們打包的時候將域名寫死了這就出錯了。

解決的方法固然很簡單將publicPath換下就行了。

但是這種解決方法并不穩妥，因為我們依賴服務端并不修改靜態資源存儲的域名。這顯然是不靠譜的。

那么為什么我們不將打包出來的HTML中script標簽的src屬性變成相對的呢？例如平臺要求的js/main.js，css/main.css。

這顯然是可以的，我們試下。

結果是部分可以部分不可以–！

我們都知道webpack打包需要一個入口文件，webpack配置文件提供的entry字段提供的入口文件。

性能優化的時候，這個入口文件還會被分為至少三個文件，一個是vendor.js這是入口文件中被引入的第三方庫，基本不怎么變動可以緩存。一個是runtime.js這是每次打包都會改變的，不利于緩存，最好直接插入到HTML文件中。一個是業務代碼，基本每次發版都會變動的main.js。其中真正的入口文件是被插入到HTML中的runtime.js。

有了這些資源之后使用插件HtmlWebpackPlugin將這些資源注入到index.html中。

這些都是webpack打包的時候就確定下來的，在publicPath修改成’'并且將output.filename和output.chunkFilename改成’js/[name].[contenthash].js’之后，上面確定下來的部分生成的script標簽的src屬性為 ‘js/xxxxx.js’ 現在將這個生成的HTML和其他靜態資源傳到活動平臺，發布之后我們發現頁面正常。但是還有一部分有問題。

這部分是動態加載的，webpack優化的時候不出現在首屏的部分我們會現在稍后加載，或者說使用webpack切割代碼的功能讓它動態加載出來。具體方法就是 import('./a.js')這種形式。

那么這樣動態加載出來的文件有什么問題呢？

首先動態加載的模塊是通過webpack后期自動構建一個script標簽然后插入的HTML中然后加載執行的。

既然是后期動態添加的，那么活動平臺的統一替換標簽的src就沒有作用到這個動態添加的標簽上，這個標簽的src還是js/xxx.js這種形式，這就報錯了。

小結：

為了解決線上靜態資源地址會變的問題，將HTML文件中替換線上資源地址的工作重新交還給活動平臺自身。具體表現為HTML中引入的資源都是相對地址’js/xxx.js’或者’css/xxx.css’這種形式，這樣就解決了我們寫死線上資源地址，但是活動平臺替換后我們不知道導致的問題。

具體配置修改：

publicPath從’//xxxx.com/xx/xxx/‘變成了’’

filename和chunkFilename從’xxx.js’變成了’js/xxx.js’

上面的配置得到的src就是 ‘’ + ‘js/xxx.js’ -> ‘js/xxx.js’ 這正是我想要的。

但是通過這個可以看出來還有一種方法可以做到。

將publicPath設置為’js/’，filename還保持’xxx.js’這樣也能得到’js/xxx.js’。

但這是不行的，因為publicPath的語義是所有靜態資源的公共路徑前綴。這么一搞不僅得到了’js/xxx.js’還得到了’js/xxx.css’等。

注：HTML中被注入的script的src屬性和動態生成的script標簽的src屬性都是通過publicPath + filename得到的。

到這里主要矛盾是活動平臺的地址替換并不能作用到動態添加的script標簽，導致js/xxx.js這種形式并沒有被替換。其次編譯代碼的時候我們并不知道publicPath的值是什么，只有等到代碼執行，也就是活動平臺替換script標簽的src屬性之后才能知道。但是publicPath是在編譯的時候寫死的。

怎么讓publicPath變成動態的？讓publicPath在代碼執行的時候動態獲取被替換之后的script標簽的src屬性，然后解析出其中的path設置上，這樣后面動態生成的script標簽的src就可以正常訪問，得到正確的地址。

翻閱文檔可以找到這段描述：

在編譯時(compile time)無法知道輸出文件的 publicPath 的情況下，可以留空，然后在入口文件(entry file)處使用自由變量(free variable) __webpack_public_path__，以便在運行時(runtime)進行動態設置。

__webpack_public_path__ = myRuntimePublicPath// 應用程序入口的其他部分

這就給了我們動態修改publicPath的能力。

看到了可行的希望。

那么這個原理是啥呢？翻看編譯過后未壓縮的代碼可以看到如下內容：

// __webpack_public_path__ __webpack_require__.p = "";

上面的屬性p就是我們配置的publicPath，在編譯后的代碼內部是被存在一個對象的屬性上的。如果webpack暴露給我們這個對象，我們自己是可以修改的。當然也可以看出，這個必須代碼一執行就需要修改，否則后面會有問題。這就是為什么修改publicPath的代碼要放在入口文件頂部的原因。

__webpack_public_path__ = myRuntimePublicPath

為什么這段代碼就能完成__webpack_require__.p的修改呢？

例如：

__webpack_public_path__ = 'publicPath/'

會變成:

{"./src/config.js":/*!***********************!*\!*** ./src/config.js ***!\***********************//*! no static exports found *//***/ (function(module, exports, __webpack_require__) {eval("__webpack_require__.p = 'publicPath/'\n\n\n//# sourceURL=webpack:///./src/config.js?");/***/ }) }

可以看到兩點，一個是模塊被編譯成被一個函數包裹的代碼塊，并且函數的最后一個入參是__webpack_require__。第二是代碼__webpack_public_path__變成了__webpack_require__.p。

這就證明了webpack自身提供了我們動態修改publicPath的能力。

最后我們還發現了如下代碼：

// script path function function jsonpScriptSrc(chunkId) {return __webpack_require__.p + "js/" + chunkId + ".index.js" }

這段代碼是用于獲取動態加載的script的src屬性的。這里也看到了__webpack_require__.p的身影。

注：為啥是chunkId + “.index.js”？當沒有指定動態引入的模塊的名字的時候就是0.index.js, 1.index.js, 2.index.js…

好，現在我們知道動態的publicPath是可以實現的。

還有一個問題，我們怎么在入口JS中獲取這個script標簽的src屬性呢？

并沒有手段直接獲取JS當前標簽的DOM對象，但是我們可以換個方法，JS可以通過屬性id獲取對應的DOM。

但是HtmlWebpackPlugin插入標簽的時候并沒有提供id屬性。

雖然沒有提供id，但是卻提供了開發相關插件的能力，這樣我們可以通過開發HtmlWebpackPlugin的插件來給對應的script標簽加上id。這樣我們就拿到了對應的src解析出了靜態資源存儲的path。

上面的方法我試了一下，是可以的。但是只可以了一半。我們能做的這一半，做完了。剩下的一半也是無能為力了。

通過上面的方法，我們得到了//xx.com/xx/xx/這個線上的publicPath。然后動態生成的js的filename是js/xxx.js，那么拼起來就是//xx.com/xx/xx/js/xx.js這種形式，這中間多了一個js/。并且這個我們去除不了。所以還是破產了。

但我覺得這并不是我們的問題。

本身我們打包出來的文件是在文件夾js目錄下，并且傳上去之后得到的目錄也是js/xxx.js但是實際替換的時候，目錄結構卻變了，沒有了js/這一層。這有點怪了。

所以破產了。

但是如果url有能力去除后面部分倒還是可以的，但是明顯不行啊。例如 //xxx.com/a/b/…/c 表示的是不要b/這一層，但是不要b/這一層是由b/后面部分決定的，如果可以由b/這部分前面部分決定就好了。

還有如果我們可以實現上面提到的jsonpScriptSrc這個函數到也可以，直接將js/這部分去掉就好了。

總結：

上面對于src="js/xxx.js"這部分js/的替換分為了兩部分，一部分是靜態生成的，webpack打包出來的HTML模板就是這樣的。這部分會由活動平臺自動替換成線上的資源路徑。

第二部分是動態生成的資源部分，這部分我們需要自己手動替換，方法是，動態修改publicPath，拼接完成，但是因為目錄層級的改變，我們失敗了。

對于這個問題的解決方案是上傳到活動平臺的代碼不要使用動態引入JS。

總結

以上是生活随笔為你收集整理的修改webpack的publicPath为动态设置以适配公司活动平台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。