一、为什要使用WebPackcss
现今的不少网页其实能够看作是功能丰富的应用,它们拥有着复杂的JavaScript代码和一大堆依赖包。为了简化开发的复杂度,前端社区涌现出了不少好的实践方法:html
这些改进确实大大的提升了咱们的开发效率,可是利用它们开发的文件每每须要进行额外的处理才能让浏览器识别,而手动处理又是很是繁琐的,这就为WebPack类的工具的出现提供了需求。前端
二、什么是Webpackreact
webpack是近期最火的一款模块加载器兼打包工具,它能把各类资源,例如JS(含JSX)、coffee、样式(含less/sass)、图片等都做为模块来使用和处理。webpack
咱们能够直接使用 require(XXX) 的形式来引入各模块,即便它们可能须要通过编译(好比JSX和sass),但咱们无须在上面花费太多心思,由于 webpack 有着各类健全的加载器(loader)在默默处理这些事情,这块咱们后续会提到。git
WebPack能够看作是模块打包机:它作的事情是,分析你的项目结构,找到JavaScript模块以及其它的一些浏览器不能直接运行的拓展语言(Scss,TypeScript等),并将其转换和打包为合适的格式供浏览器使用。github
三、WebPack和Grunt以及Gulp相比有什么特性web
其实Webpack和另外两个并无太多的可比性,Gulp/Grunt是一种可以优化前端的开发流程的工具,而WebPack是一种模块化的解决方案,不过Webpack的优势使得Webpack在不少场景下能够替代Gulp/Grunt类的工具。npm
Grunt和Gulp的工做方式是:在一个配置文件中,指明对某些文件进行相似编译,组合,压缩等任务的具体步骤,工具以后能够自动替你完成这些任务。json
Webpack的工做方式是:把你的项目当作一个总体,经过一个给定的主文件(如:index.js),Webpack将从这个文件开始找到你的项目的全部依赖文件,使用loaders处理它们,最后打包为一个(或多个)浏览器可识别的JavaScript文件。
若是实在要把两者进行比较,Webpack的处理速度更快更直接,能打包更多不一样类型的文件。
其优点主要能够归类为以下几个:
一、webpack 是以 commonJS 的形式来书写脚本滴,但对 AMD/CMD 的支持也很全面,方便旧项目进行代码迁移。
二、能被模块化的不只仅是 JS 了。
三、开发便捷,能替代部分 grunt/gulp 的工做,好比打包、压缩混淆、图片转base64等。
四、扩展性强,插件机制完善,特别是支持 React 热插拔(见 react-hot-loader )的功能让人眼前一亮。
咱们谈谈第一点。以 AMD/CMD 模式来讲,鉴于模块是异步加载的,因此咱们常规须要使用 define 函数来帮咱们搞回调:
define(['package/lib'],function(lib){ function foo(){ lib.log('hello world!'); } return{ foo:foo }; });
另外为了能够兼容 commonJS 的写法,咱们也能够将 define 这么写:
define(function(require, exports, module){ var someModule = require("someModule"); var anotherModule = require("anotherModule"); someModule.doTehAwesome(); anotherModule.doMoarAwesome(); exports.asplode = function(){ someModule.doTehAwesome(); anotherModule.doMoarAwesome(); }; });
然而对 webpack 来讲,咱们能够直接在上面书写 commonJS 形式的语法,无须任何 define (毕竟最终模块都打包在一块儿,webpack 也会最终自动加上本身的加载器):
var someModule = require("someModule"); var anotherModule = require("anotherModule"); someModule.doTehAwesome(); anotherModule.doMoarAwesome(); exports.asplode = function(){ someModule.doTehAwesome(); anotherModule.doMoarAwesome(); };
这样撸码天然更简单,跟回调神马的说 byebye~不过即便你保留了以前 define 的写法也是能够滴,毕竟 webpack 的兼容性至关出色,方便你旧项目的模块直接迁移过来。
//咱们常规直接使用 npm 的形式来安装:
$ npm install webpack -g //固然若是常规项目,仍是把依赖写入 package.json 包去,更人性化:
$ npm init $ npm install webpack --save-dev
每一个项目下都必须配置有一个 webpack.config.js ,它的做用如同常规的 gulpfile.js/Gruntfile.js ,就是一个配置项,告诉 webpack 它须要作什么。
咱们看看下方的示例:
var webpack = require('webpack'); var commonsPlugin = new webpack.optimize.CommonsChunkPlugin('common.js'); module.exports = { //插件项
plugins:[commonsPlugin], //页面入口文件配置
entry:{ index : './src/js/page/index.js' }, //入口文件输出配置
output: { path:'dist/js/page', filename:'[name].js' }, module: { //加载器配置
loaders: [ { test: /\.css$/, loader: 'style-loader!css-loader'}, { test: /\.js$/, loader: 'jsx-loader?harmony'}, { test: /\.scss$/, loader: 'style!css!sass?sourceMap'}, { test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192'} ] }, //其它解决方案配置
resolve: { root:'E:/github/flux-example/src',//绝对路径
extensions: [ '', '.js', '.json', '.scss' ], alias: { AppStore : 'js/stores/AppStores.js', ActionType : 'js/actions/ActionType.js', AppAction : 'js/actions/AppAction.js' } } };
(1) plugins 是插件项,这里咱们使用了一个 CommonsChunkPlugin 的插件,它用于提取多个入口文件的公共脚本部分,而后生成一个 common.js 来方便多页面之间进行复用。
(2)entry 是页面入口文件配置,output 是对应输出项配置(即入口文件最终要生成什么名字的文件、存放到哪里),其语法大体为:
{ entry: { page1:"./page1", //支持数组形式,将加载数组中的全部模块,但以最后一个模块做为输出
page2: ["./entry1","./entry2"] }, output: { path:"dist/js/page", filename:"[name].bundle.js" } }
该段代码最终会生成一个 page1.bundle.js 和 page2.bundle.js,并存放到 ./dist/js/page 文件夹下。
(3) module.loaders 是最关键的一块配置。它告知 webpack 每一种文件都须要使用什么加载器来处理:
module: { //加载器配置
loaders: [ //.css 文件使用 style-loader 和 css-loader 来处理
{ test: /\.css$/, loader: 'style-loader!css-loader' }, //.js 文件使用 jsx-loader 来编译处理
{ test: /\.js$/, loader: 'jsx-loader?harmony' }, //.scss 文件使用 style-loader、css-loader 和 sass-loader 来编译处理
{ test: /\.scss$/, loader: 'style!css!sass?sourceMap' }, //图片文件使用 url-loader 来处理,小于8kb的直接转为base64
{ test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192' } ] }
如上,"-loader"实际上是能够省略不写的,多个loader之间用“!”链接起来。
注意:全部的加载器都须要经过 npm 来加载,并建议查阅它们对应的 readme 来看看如何使用。
拿最后一个 url-loader 来讲,它会将样式中引用到的图片转为模块来处理,使用该加载器须要先进行安装:
npm install url-loader -save-dev
配置信息的参数“?limit=8192”表示将全部小于8kb的图片都转为base64形式(其实应该说超过8kb的才使用 url-loader 来映射到文件,不然转为data url形式)。
(4)最后是 resolve 配置,这块很好理解,直接写注释了:
resolve: { //查找module的话从这里开始查找
root:'E:/github/flux-example/src',//绝对路径 //自动扩展文件后缀名,意味着咱们require模块能够省略不写后缀名
extensions: [ '', '.js', '.json', '.scss' ], //模块别名定义,方便后续直接引用别名,无须多写长长的地址
alias: { AppStore : 'js/stores/AppStores.js',//后续直接 require('AppStore') 便可
ActionType : 'js/actions/ActionType.js', AppAction : 'js/actions/AppAction.js' } }
webpack 的执行也很简单,直接执行
$ webpack --display-error-details
便可,后面的参数“--display-error-details”是推荐加上的,方便出错时能查阅更详尽的信息(好比 webpack 寻找模块的过程),从而更好定位到问题。
其余主要的参数有:
$ webpack --config XXX.js //使用另外一份配置文件(好比webpack.config2.js)来打包
$ webpack --watch //监听变更并自动打包
$ webpack -p //压缩混淆脚本,这个很是很是重要!
$ webpack -d //生成map映射文件,告知哪些模块被最终打包到哪里了
其中的 -p 是很重要的参数,曾经一个未压缩的 700kb 的文件,压缩后直接降到 180kb(主要是样式这块一句就独占一行脚本,致使未压缩脚本变得很大)。
上面说了那么多配置和执行方法,下面开始说说寻常页面和脚本怎么使用呗。
直接在页面引入 webpack 最终生成的页面脚本便可,不用再写什么 data-main 或 seajs.use 了:
<!DOCTYPE html>
<html>
<head lang="en">
<meta charset="UTF-8">
<title></title>
</head>
<body>
<script src="dist/js/page/common.js"></script>
<script src="dist/js/page/index.js"></script>
</body>
</html>
能够看到咱们连样式都不用引入,毕竟脚本执行时会动态生成<style>并标签打到head里。
各脚本模块能够直接使用 commonJS 来书写,并能够直接引入未经编译的模块,好比 JSX、sass、coffee等(只要你在 webpack.config.js 里配置好了对应的加载器)。
咱们再看看编译前的页面入口文件(index.js):
require('../../css/reset.scss');//加载初始化样式
require('../../css/allComponent.scss');//加载组件样式
var React = require('react'); var AppWrap = require('../component/AppWrap'); //加载组件
var createRedux = require('redux').createRedux; var Provider = require('redux/react').Provider; var stores = require('AppStore'); var redux = createRedux(stores); var App = React.createClass({ render:function(){ return ( <Provider redux={redux}> { function(){ return <AppWrap />; } } </Provider> ); } }); React.render(<App/>, document.body);
一切就是这么简单,后续各类有的没的,webpack 都会帮你进行处理。