一移稳、需求背景
在項目開發(fā)中，從設計師那里拿到圖片后摔笤，不知道小伙伴們都是怎么處理的呢？
是不是都習慣了將圖片扔到tinypng.com進行壓縮后再放回到項目上提交垦写？
由于設計師給的圖片一般是原圖吕世，直接放到項目上，會因為大小過大梯投，影響用戶體驗命辖。所以開發(fā)在拿到圖片后，一般會先進行壓縮分蓖，犧牲一點品質(zhì)尔艇，換取大小上的優(yōu)化。
而每次手動壓縮再上傳的流程么鹤，效率著實不高终娃，對一個程序員來說，不斷做重復工作時蒸甜，就要考慮是不是該換種操作了棠耕。
二、工具選擇
像 tinypng.com 在線工具迅皇，背后使用了多種壓縮方式昧辽，能極大程度地降低圖片大小，壓縮率很高登颓。但同時也存在一些局限搅荞，比如只能壓縮png和jpg、受網(wǎng)絡線路影響框咙、壓縮接口有次數(shù)限制咕痛，需要付費解鎖等。
而本地工具 imagemin喇嘱，不僅沒有網(wǎng)絡限制茉贡，也不需要付費，通過插件體系者铜，還可以加載不同的壓縮工具處理各種情況腔丧。
經(jīng)過簡單的對比，選擇了 imagemin 作為壓縮工具作烟。
三愉粤、壓縮時機
在項目中的自動化操作，很自然就想到了 webpack拿撩。通過使用 webpack衣厘，在 build 的時候進行壓縮。打包出來的圖片就是壓縮好的了，而且 webpack 中影暴，各種插件也比較全错邦，很容易就能找到合適的壓縮插件。
但使用 webpack 有個問題型宙，在每次構建時撬呢，都會執(zhí)行壓縮操作，而且壓縮過的文件也會被再次執(zhí)行壓縮早歇。圖片多的情況下倾芝，壓縮過程耗時也會相對更多讨勤。
那有沒有在提交新文件前進行壓縮的操作箭跳？
答案是 line-staged。
line-staged 一般用的比較多的地方是配合 eslint 進行提交前的格式校驗和格式化潭千，但其實它的作用遠不止于此谱姓。它的作用很純粹，就是再提交更改前刨晴，將更改文件的 path 作為參數(shù)傳到配置的命令行工具上屉来，也就是說，我們可以再這里配置壓縮工具狈癞，就能夠在提交圖片前進行壓縮茄靠。
四、命令行工具
line-staged 上推薦了一個圖片壓縮的工具：imagemin-lint-staged蝶桶。但是其使用的是無損壓縮慨绳，不能滿足項目的需求。所以我參考 imagemin-lint-staged 自己寫了一個：imagemin-linter真竖∑暄可進行有損壓縮與無損壓縮的配置，使用如下：
安裝：
npm i -D husky lint-staged imagemin-linter
配置 package.json：
...
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{png,jpeg,jpg,gif,svg}": "imagemin-linter",
},
...
配置完成后恢共，在每次提交更改時战秋，就能自動對圖片進行壓縮。
