Electron打包配置 + package.json的常用配置項及其用法解析_MElement的博客-CSDN博客_electron打包配置
Electron打包配置 + package.json的常用配置項及其用法解析
MElement 於 2021-08-25 06:44:46 發布 871 收藏 3文章標簽： electron json node.js版權
Electron Build配置基礎配置{ "name": "demo01", //項目名稱 "version": "0.0.2", //版本號 "author": "神氣寶貝小鄧", //作者 "description": "xxx",//項目描述 "main": "main.js", "scripts": {//利用快捷腳本命令,運行Electron相關默認命令 "test": "echo \"Error: no test specified\" && exit 1", "start": "electron .", //比如 "npm run start" 可代替 "electron ."運行 "electron build": "electron-builder --win --x64" }, "keywords": [ //關鍵詞（便於使用者在npm中搜索） "xxxx" ], 1234567891011121314electron-builder打包詳細配置 “build”: { } "build": { "productName":"xxxx",//項目名 這也是生成的exe文件的前綴名 "appId": "xxxxx",//包名 "copyright":"xxxx",//版權 信息 "compression": "store", // "store" | "normal"| "maximum" 打包壓縮情況(store 相對較快)，store 39749kb, maximum 39186kb "directories": { "output": "build" // Build輸出文件夾 }, "asar": false, // 是否使用asar打包 "extraResources": { // 拷貝dll等靜態文件到指定位置 "from": "./app-update.yml", "to": "./b.txt" }, "win": { "icon": "xxx/icon.ico"//圖標路徑, "extraResources": { // 拷貝dll等靜態文件到指定位置(用於某個系統配置) "from": "./app-update.yml", "to": "./b.txt" } }, "nsis": { "oneClick": false, // 是否一鍵安裝(是否詢問用戶安裝下一步安裝) "guid": "xxxx", //注冊表名字，不推薦修改 "perMachine": true, // 是否開啟安裝時權限限制（此電腦或當前用戶） "allowElevation": true, // 允許請求提升。 如果為false，則用戶必須使用提升的權限重新啟動安裝程序。 "allowToChangeInstallationDirectory": true, // 允許修改安裝目錄 "installerIcon": "./aaa.ico", // 安裝圖標 必須是大於256*256的.ico "uninstallerIcon": "./build/icons/bbb.ico", //卸載圖標 必須是大於256*256的.ico "installerHeaderIcon": "./aaa.ico", // 安裝時的頭部圖標 必須是大於256*256的.ico "createDesktopShortcut": true, // 創建桌面圖標 "createStartMenuShortcut": true, // 創建開始菜單圖標 "shortcutName": "xxxx" // 圖標名稱 必須是大於256*256的.ico } }}1234567891011121314151617181920212223242526272829303132333435package.json的所有常用配置項及其用法補充寫在前面在前端開發中，npm已經是必不可少的工具了。使用npm，不可避免的就要和package.json打交道。平時package.json用得挺多，但是沒有認真看過官方文檔。本文結合npm官方文檔以及自己平時使用過程中的感悟，談一談package.json。
初始化使用npm init命令就可以初始化一個package.json文件。在初始化的過程中，會叫用戶輸入name, version等等信息，當然，你都可以忽略。一路點回車，就生成了下面這樣一個初始化的package.json。
{ "name": "test", // 假如項目叫做test "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "license": "ISC"}1234567891011上面的package.json包含了項目的名稱，版本號，描述，入口文件，執行腳本，作者，開源協議等。package.json的內容遠不止這些，下面將一一進行介紹。在開發業務項目和開發組件庫的時候，package.json是略有不一樣的。我會把我認為重要的配置項加黑標識出來。
詳細介紹name: 這個很好理解，就是package的名稱。不過需要注意的是，name有長度限制(雖然一般都不會超)，而且name不能以 【點】 或者 【下划線】開頭，name中不能有大寫字母。這個是每一個package必須的。在業務代碼中，通過require(${name})就可以引入對應的程序包了。version: package的版本。對於業務項目來說，這個往往不太重要，但是如果你要發布自己的項目，這個就顯得十分重要了。name和version共同決定了唯一一份代碼。npm是用[npm-semver來解析版本號的。我們一般見到的都是大版本.次要版本.小版本這種版本號，比如16.1.0。版本號的規則、含義其實蠻多的，可以參考這篇文章。desription：包的描述。開發組件庫時必需，簡明的向庫的使用者介紹這個庫是干嘛的。對於公司的業務項目，這個配置項一般無所謂。keywords：關鍵詞。一個字符串數組，對這個npm包的介紹。組件庫必需，便於使用者在npm中搜索。對於公司業務項目，這個配置一般無所謂。homepage： 項目主頁。對於開發組件庫來說挺有用的。bugs：開發者的聯系方式，代碼庫的issues地址等。如果代碼使用者發現了bug，可以通過這個配置項找到提bug的地方。license：開源協議。對於開源組件庫，這個十分重要。之前react還因為這事兒沒少被社區嫌棄。開源協議略微復雜，用阮一峰前輩的一張圖來說明一下吧。注：圖里少了ISC, ISC和BSD差不多
author：項目的作者。可以為字符串，對象。contributors：項目的貢獻者。author的數組。main：代碼入口。這個十分重要，特別是對於組件庫。當你想在node_modules中修改你使用的某個組件庫的代碼時，首先在node_modules中找到這個組件庫，第一眼就是要看這個main，找到組件庫的入口文件。在這個入口文件中再去修改代碼吧。scripts：指定了運行腳本命令的npm命令行縮寫。十分重要。來看一個例子：
"scripts": { "dev": "NODE_ENV=dev webpack-dev-server --progress --hot --host 0.0.0.0 --port 8089", "test": "NODE_ENV=test webpack --config webpack.test.config.js --progress", "online": "NODE_ENV=production webpack --config webpack.online.config.js --progress", "build": "webpack", "node": "node server.js" },1234567在命令行輸入：npm run dev , 對應的命令就會被執行。這里有一個地方需要注意，當執行npm run xxx的時候，node_modules/.bin/目錄會在運行時被加入系統的PATH變量。上面的例子，當我們在命令行輸入：npm run build時，其實真正執行的命令是node_modules/.bin/webpack而不是webpack。所以，當你的webpack並未全局安裝時，直接在命令行輸入：webpack是會報錯的。因為你的webapck是安裝在node_modules/.bin/下面的。
directories：對整個代碼結構的描述。告訴代碼包使用者可以在哪里找到對應的文件。
files：數組。表示代碼包下載安裝完成時包括的所有文件。
repository：對於組件庫很有用。讓組件庫使用者找到你的代碼庫地址。這個配置項會直接在組件庫的npm首頁生效。例子:
"repository": { "type": "git", "url": "git+https://github.com/CoyPan/react-scroll-to-show-cb.git"},1234config：用於添加命令行的環境變量。具體用法見這里。
dependencies：項目的依賴。通過npm install --save安裝的包會出現在這里。注意，不要把測試工具、代碼轉換器或者打包工具等放在這里。當你在命令行里面使用npm install react --save時，react就會出現在dependencies。默認是安裝最新的版本。如果想安裝某個特定的版本，可以npm install react@15.6.2。以下的dependencies，格式都是合法的，
"dependencies" : { "foo" : "1.0.0 - 2.9999.9999", "bar" : ">=1.0.2 <2.1.2", "baz" : ">1.0.2 <=2.3.4", "boo" : "2.0.1", "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0", "asd" : "http://asdf.com/asdf.tar.gz", "til" : "~1.2", "elf" : "~1.2.3", "two" : "2.x", "thr" : "3.3.x", "lat" : "latest", "dyl" : "file:../dyl" }1234567891011121314我們常見的是下面這些：
"dependencies": { "foo": "1.0.0", // 指定了就是1.0.0版本 "bar": "~1.2.2", // 安裝版本號不低於1.2.2的1.2.x的最新版本，例如:1.2.3， 1.2.4等等。1.2.1 ，1.3.x 等就不行了 "baz": "ˆ1.2.2", // 安裝版本號不低於1.2.2的1.x.x的最新版本，例如: 1.2.7，1.3.1，1.7.8等。1.2.1 ，2.0.0 等就不行了。注意，如果配置是^0.x.x，則和~0.x.x的效果一樣。 "lat": "latest" // 安裝最新版本}123456dependencies 還可以像下面這樣配置：
"dependencies": { "foo": "git+ssh://git@github.com:foo/foo.git#v1.0.1",}123foo組件的地址為git+ssh://{foo代碼庫的ssh地址}#v{foo的版本號}
這樣的配置在下面這種場景十分有用：
組內的許多項目都有同一個功能，把這個功能抽出來做成組件是很自然的想法。但是每個項目都有自己的代碼庫，公司也沒有內部的npm庫，組件應該放在哪里呢？可以專門為組件新建一個代碼倉庫，將組件放在這里開發、迭代。這樣，各個項目都可以引用該組件：只需要在dependencies中將組件配置成上述的形式。至於組件的版本，可以通過git tag來控制。
dependencies還有其他的配置方式，具體在這里查看。
devDependencies：項目的依賴。通過npm run install --save-dev安裝的包會出現在這里。主要是在開發過程中依賴的一些工具。用法與dependencies相似。
bundledDependencies：數組，打包時的依賴。如果配置了bundledDependencies，在項目中執行 npm pack將項目打包時，最后生成的.tgz包中，會包含bundledDependencies中配置的依賴。bundledDependencies中的依賴必須在devDependencies或者dependencies中聲明過。
peerDependencies: 指定當前組件的依賴以其版本。如果組件使用者在項目中安裝了其他版本的同一依賴，會提示報錯。
engines：指定項目所依賴的node環境、npm版本等。
private：如果設為true，無法通過npm publish發布代碼。
bin：用來指定各個內部命令對應的可執行文件的路徑。具體用法這里不多講了。詳情可以點擊這里。
總結本文涵蓋了package.json絕大部分的配置項。我的觀點是：如果是公司的業務項目，對於package.json，一般情況下，我覺得只需要關注好scripts，dependencies，devDependencies這三個地方就夠了。而對於開源的組件庫，則至少需要關注好上面標黑的幾個點。理解好重要配置的含義，提升開發效率，減少踩坑的概率。————————————————版權聲明：本文為CSDN博主「MElement」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。原文鏈接：https://blog.csdn.net/qq_41980754/article/details/119902572