libwebpackplugin 的诞生
由于作者做的 map-web 前端项目（一个基于 WebGL引擎项目），需要引入3d引擎代码库相关文件， 发现在引入 webgl 文件夹时候 ，每次需要手动 复制 / 粘贴到 map-web 项目中，包括版本测试，发版本等等。
这种手动的重复性劳动非常浪费相关开发人员的精力，因此整理了下公司前端与底层webgl的自动化项目构建方案。（ 本人是强迫症患者 -。- ）
起初脑海里面有两个方案：
通过 npm 包方式 进行引入和版本管理
相当于每次底层构建完 webgl 底层项目，修改相应 package 版本，然后 npm publish 到 npm 服务器，前端项目通过 npm install 的方式进行引入。通过 服务链接提供方式 进行引入和版本管理
相当于每次构建完 webgl 底层项目后， push 构建后的代码到自己的 cdn 服务器上，使用人员通过 script 脚本进行引入http://xxx.cdn.com/1.0.0/webgl.js。
（这里需要注意一下版本的控制，由于缓存影响，这里采用版本号即文件夹形式进行控制，同时还方便了历史版本管理， 每次构建项目到版本号对应的文件夹下面 ，类似/ dist /webgl.js -> / x.x.x /webgl.js，
至于 cdn 缓存的相关知识不是本文重点这里不作介绍 感兴趣可查看缓存相关资料）
适合自己的才是最好的
在实践的过程中发现， 由于构建项目文件数量多以及单个文件大小过大 （webgl js 需要3M多），通过方案一方式进行进行管理，每次底层webglx项目 build -> npm publish 与
前端项目 npm install -> build 的过程，在时间的耗费上是很恐怖的。
因此做了对比之后果断抛弃了这种方案， 因为方案二 只在 build -> npm pulish 耗费时间，在前端项目中只需要 script 引入外部资源就可以。
为了追求更加的方便
在做完底层库的构建流程优化之后，又有新的思考，在前端项目中（作者做的都是偏向 spa 项目），引入webgl 资源时候，难道每次版本测试或者版本发布都需要手动的去替换 script 对应版本链接的 src 吗？
脑海里第一反应就是 需要添加一个 外部资源版本配置文件，只需要修改 外部资源 版本号就可以， 在 build 时候实现自动化添加修改 script 的相应版本 src 链接到 html 中。类似：
// lib.config.js
module.exports = {
libs: [{
name: "lib1-name ",
version: "x.x.x", // 通过配置来修改此版本号
path: "http://xxx.xxx.com"
}, {
name: "lib2-name ",
version: "x.x.x",
path: "http://xxx.xxx.com"
}]
}
// webpack.config.js
const LibWebpackPlugin = require("lib-webpack-plugin");
const libs = require("./lib.config.js").libs;
module.exports = {
entry: "",
output: {},
plugins: [
new LibWebpackPlugin(libs)
]
}
个人感觉 配置文件除了解耦和方便管理的好处，还避免你不够细心的话 手动错误修改了 src
至此初步方案已经成型。
因此 lib-webpack-plugin 诞生了。
libwebpackplugin 的第一个版本
首先这是一个 webapck 插件， 既然是插件 就要先了解 webpack 的 Compiler模块 和 hooks 机制, 中文链接附上 compiler-hook 。
由于本插件基于 html-webpack-plugin 插件，因此还需要了解 此插件的相关 hooks
libwebpackplugin 的具体使用和源代码可以查看 lib-webpack-plugin
由于这是第一个版本， 功能很简单，只是暂时满足了初步应用，我会继续优化迭代下一个版本 😝
其他
很意外的是，居然有人开始引用这个插件了（目前只是一个待优化的初略版本），看来大家在做项目的时候都有这方面的需求，这给我继续迭代下个版本无形中又加了不少动力。（手动比 ❤️）
