一、需求背景
在项目开发中，从设计师那里拿到图片后，不知道小伙伴们都是怎么处理的呢？
是不是都习惯了将图片扔到tinypng.com进行压缩后再放回到项目上提交？
由于设计师给的图片一般是原图，直接放到项目上，会因为大小过大，影响用户体验。所以开发在拿到图片后，一般会先进行压缩，牺牲一点品质，换取大小上的优化。
而每次手动压缩再上传的流程，效率着实不高，对一个程序员来说，不断做重复工作时，就要考虑是不是该换种操作了。
二、工具选择
像 tinypng.com 在线工具，背后使用了多种压缩方式，能极大程度地降低图片大小，压缩率很高。但同时也存在一些局限，比如只能压缩png和jpg、受网络线路影响、压缩接口有次数限制，需要付费解锁等。
而本地工具 imagemin，不仅没有网络限制，也不需要付费，通过插件体系，还可以加载不同的压缩工具处理各种情况。
经过简单的对比，选择了 imagemin 作为压缩工具。
三、压缩时机
在项目中的自动化操作，很自然就想到了 webpack。通过使用 webpack，在 build 的时候进行压缩。打包出来的图片就是压缩好的了，而且 webpack 中，各种插件也比较全，很容易就能找到合适的压缩插件。
但使用 webpack 有个问题，在每次构建时，都会执行压缩操作，而且压缩过的文件也会被再次执行压缩。图片多的情况下，压缩过程耗时也会相对更多。
那有没有在提交新文件前进行压缩的操作？
答案是 line-staged。
line-staged 一般用的比较多的地方是配合 eslint 进行提交前的格式校验和格式化，但其实它的作用远不止于此。它的作用很纯粹，就是再提交更改前，将更改文件的 path 作为参数传到配置的命令行工具上，也就是说，我们可以再这里配置压缩工具，就能够在提交图片前进行压缩。
四、命令行工具
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",
},
...
配置完成后，在每次提交更改时，就能自动对图片进行压缩。
