文/ziven
标题图/来自网络
有时候，开发过程中，有意无意都会慢慢有自己的一些积累，比如说写了一个动画组件，或者写了一个比较漂亮，体验比较好的插件。这时候我们都希望无差别的在以后的工作中能够即时的使用这些我们曾经做过的东西。把开发过的组件发布到npm 是个不错的方式。
本坑在开发vue项目中也有类似的经历，但是对webpack打包模块化不是很清楚，如果觉得头痛webpack的配置，在开发过程中不妨先把webpack放一边，先看看npm publish，直接调用vue文件,以此一步步增强了解整个发布开发组件过程。
这种方式简单粗暴，首先指定一个目录，执行<pre>npm init</pre>这时候就会出现如下图情况反馈
如果觉得每个选项不知道回答什么，就一直回车就好，最后在文件夹中会多出一个package.json.这里直接给出整个package.json
<pre>{
"name": "vuetest",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo "Error: no test specified" && exit 1"
},
"author": "",
"license": "ISC"
}</pre>
它已经有了主入口文件main.js，如果没有，手动添加，这里把自己要用的vue插件替换掉index.js，比如我的是transform.vue 一个3d显示的图片的插件，就换成 “main”:"transform.vue" ,组件放在与package.json 同级目录下。
执行发布前必须要登录,要有自己的账号，这里不再说了，找到npm官网进行注册 ，npm发布不能使用淘宝镜像，发布可能无法成功，这时候设置为npm默认配置就行，如下
<pre>npm config set registry http://registry.npmjs.org </pre>
以上是最简单的npm发布组件，并且直接使用vue文件，很显然是没有扩展性的。这时候没有webpack不行，它可以对vue进行整理编译，模块化成js文件，webpack的配置可以兼容多种应用方式。对于不太清楚webpack到底是啥，配置项有哪些的，其实不要忙着马上去上手配置插件，往往会造成很多弯路。先要搞清楚来龙去脉才是重要的。
webpack与gulp区分与理解
很多初学者有些疑惑这两者的区别，包括我在内，往往都用鱼和熊掌来比喻两者，所以很多人都惯性认为他们的目标是一样的。其实两者是可以同时使用在一个项目之中的。它们有不一样的重点，也有不一样的工作方式，具体目标也并不相同，拿来进行比较是不太正确的。
webpack最大的特点就是模块化打包，这是最大的特点，当我们开发的组件越来越多时，它可以满足我们进行有条件，有选择的加载某些模块。当然它也可以压缩我们要打包的文件了。
gulp就是自动化构建工具，所谓自动化，就是什么都不用管，它自动去完成，像比如说自动压缩图片，合并图片，合并样式，编译less,等等，本坑还没有认真学习它，也只是大概的了解，据我所知，他在压缩文件上有很多花样，以后将会出个专题讨论它。
所以总的来说，Gulp是一个工具，而webpack是模块化技能与方法于一身的'物件'。Gulp可以使用webpack插件等诸多插件来进行自动化效果，从而达到多者插件并用的效果
module.export之前发生了什么
打开我的vue库地址，我们来看看三个要注意的文件，其中前两个更加重要一些。webpack配置文件。webpack配置的入口文件，运行这些配置将导出最后的打包文件
入口文件中看到module.export导出了我们写得模块。
那么为啥export后就能在别处使用呢？我不禁要问。于是我就去找导出来的是什么？下面就是我找到的答案。
其实如果不用webpack打包，不结合加载器，export出来的还是vue(可以实际操作以下)，很显然这是不能用在没有vue构建环境之下的。因为没有vue-loader,vue得不到解析。vue是html，css，js 的结合体，通过webpack打包，webpack有诸多loader，其中vue-loader就是能够解释vue并且导出三个不同的部分，然后给其他的loader继续处理。而到了module.export出来的是按照一种格式形成的模块。这个模块可以require，可以import，可以在html中js,css 直接引用等等达到加载这些模块。这样说起来心里是不是有些数了呢？还是更迷糊了呢？
一步两步的构建自己的插件库
不懂的我，从vue-cli本身的webpack配置开始
第一步，vue-cli 脚手架搭建vue项目
第二步，复制黏贴自己要发布的vue组件，放到components里，我的是transform.vue，一个3d随鼠标显示图片的插件。packjson设置main属性为dist/xxxxxx.js，src文件写好webpack的入口文件js，内容可以看本坑github的例子。把webpack.base.conf.js内容复制到自己的webpack文件中，进行简单修改，比如说里面一些路径改下，其他可以不改。
第三步，执行webpack ，打包完成了。
新建个demo文件夹,可以看到是否可以使用，正常使用
这些都是大致的打包，打包配置将在今后进行不断改进。
(课外关键题)--打包格式中的‘小学问’
上面说到经过webpack后export导出了一定格式的模块或者多个模块文件。这个格式就是CommonJS。那么要问了，打包格式有哪些呢？说起来，大概以下几种，commonjs,cmd，amd，umd。下面是对他们的基本解释。
CommonJS：js 模块化的目的是为了逻辑清楚，复用方便，commonjs就是在这样的需求下诞生的模块化规范。我们在nodejs开发的实际代码中看到require，export，module就是其语法定义。这样说来nodejs，npm就是采用了commonjs，但是nodejs也加了其他东西，并非都是commonjs一家构成。
AMD：然而commonjs不是万能的，因为它的致命缺点之一就是没办法在浏览器中引用，为什么呢？举个例子，它的require如果运用到浏览器，网络的高延时很可能让require加载失败，不像服务器可以冲本地require。那怎么办呢？异步加载呗！这就是AMD出现原因，它的全名翻译是异步模块定义（define(['dep1','dep2'],function(dep1,dep2){...});），熟悉require.js对AMD就再了解不过了。
CMD:CMD是AMD的变种，有些不同,都在传送门里，
UMD:同时以 AMD、CommonJS2 和全局属性形式输出。
webpack中output.libraryTarget,它的支持有以下几种
“var” - 以一个变量形式输出： var Library = xxx (default)；
“this” - 以 this 的一个属性输出： this[“Library”] = xxx；
“commonjs” - 以 exports 的一个属性输出：exports[“Library”] = xxx；
“commonjs2” - 以 module.exports 形式输出：module.exports = xxx；
“amd” - 以 AMD 格式输出；
“umd” - 同时以 AMD、CommonJS2 和全局属性形式输出。
