webpack入門（一）——webpack 介紹

現在的網站正在演化爲web應用程序:
1. 愈來愈多的使用JavaScript。
2. 現代瀏覽器提供更普遍的接口。
3. 整頁刷新的狀況愈來愈少，甚至更多代碼在同一個頁面。（SPA）

所以有不少代碼在客戶端!
一個體量龐大的代碼庫須要好好組織。模塊系統提供代碼庫劃分紅模塊的選項。

模塊系統風格

目前有多個標準定義依賴和輸出：
1. script標籤（不要模塊系統）
2. CommonJS
3. AMD和它的一些變種
4. ES 6
5. 其它

script 標籤的樣式

下面這種就是不用模塊系統，你會怎麼去管理你的代碼。

<script src="module1.js"></script>
<script src="module2.js"></script>
<script src="libraryA.js"></script>
<script src="module3.js"></script>

模塊接口導出到全局對象,即window對象。模塊的接口能夠訪問全局對象的依賴關係
常見問題

全局衝突
嚴重依賴加載的順序
開發人員必須人工解決模塊/庫的依賴關係
大型項目，script一溜下來能夠很長,難以管理

CommonJs: 同步加載

這種風格用同步require 的方法去加載一個依賴並用暴露一個接口。 一個模塊能夠經過給export對象添加屬性或給module.exports設置值 來指定導出。

require("module");
require("../file.js");
exports.doStuff = function() {};
module.exports = someValue;

服務器端node.js用的就是這種標準。
優勢:
1. 服務器端模塊能夠重用
2. 已經有許多模塊用這種風格(npm)。生態圈良好
3. 很是簡單和容易使用。
劣勢
1. 阻塞調用不適用網絡。網絡請求是異步的。
2. 沒有並行加載機制。
哪些在用？
1. 服務端 -node.js
2. browserify
3. modules-webmake -編譯到一個包
4. wreq -客戶端

AMD: 異步加載

其它模塊系統（例如 瀏覽器） 同步加載有困難(CommonJS) 而引入的一個異步版本（和定義模塊和輸出值的一種方法 ）。

require(["module", "../file"], function(module, file) { /* ... */ });
define("mymodule", ["dep1", "dep2"], function(d1, d2) {
  return someExportedValue;
});

優勢:
1. 適合網絡的異步請求的風格
2. 並行加載多個模塊。
劣勢
1. 編碼費力，更難讀和寫
2. 看起來只是權宜之計。
哪些在用？
1. require.js
2. curl

ES6模式

ES6借鑑其它語言給javascript新加了一些語法結構，有import語法。

1 import "jquery";
2 export function doStuff() {}
3 module "localModule" {}

優勢:
1. 靜態分析很容易。
2. 不會過期的ES標準 。
劣勢
1. 瀏覽器支持須要時間。（早晚的事）
2. 不多有模塊用這種風格。生態圈
目前沒有公開的方案

開發者應當本身選擇適合本身的風格。容許現有的代碼和包能正常工做，能夠很容易地添加自定義模塊風格。

傳輸

模塊應該在客戶端執行,因此他們必須從服務器傳輸到瀏覽器。
傳輸模塊有兩個極端:
1. 一個一個地傳。
2. 所有打包在一個裏傳。

兩種用法都氾濫，可是兩種都太low了。

一個一個地傳
優勢：只有確實須要的模塊纔會傳輸過去。
缺點：許多請求意味着不少開銷。
缺點：應用程序啓動緩慢,由於請求延遲
所有一個地傳
優勢：請求的開銷更少,更少的延遲
缺點：不少暫時不須要的模塊給傳輸過去了。

分塊傳輸

更靈活的傳輸可能會更好。大多數狀況下在這兩種極端之間的折中比較好。
=>在編譯全部模塊時：把模塊切分紅小塊兒（chunks）。
這樣容許多個更小、更快的請求。有些模塊不是一開始就須要的，含有這些模塊的分塊在須要的時候能夠加載到。這樣加快了初始化速度，可是在須要用那些模塊時仍然讓你去抓更多的代碼。

開發者怎麼作「切分點」，能夠根據狀況自由抉擇。
=》一個代碼庫是可能的喲。

注意：這些觀點來自谷歌 GWT.

怎麼可能只有javascript

爲何一個模塊系統只能幫程序猿們解決javascript問題呢？還有許多其餘資源須要處理:
樣式表
圖片
web字體
html模板
等等

或者 一些預編譯和後編譯語言
coffeescript → javascript
elm → javascript
less 樣式→ css 樣式
jade 模板→ javascript 生成 html
i18n files → something
等等

這些東西應該也像下面這樣容易：

require("./style.css");

1 require("./style.less");
2 require("./template.jade");
3 require("./image.png");

靜態分析

當編譯全部這些模塊時,一個靜態分析試圖找到本身的依賴。
傳統上這隻能找到簡單的東西沒有表達 。可是
require("./template/" + templateName + ".jade") 這樣是常見的結構。
有些庫是用一些不同的風格寫的。它們有些很奇怪（難以想象）。

策略

聰明的解析辦法容許現存代碼能跑起來，若是程序猿用了一些怪異的東西，它能試圖找到兼容的解決方案。

什麼是webpack

webpack是一個模塊打包器。webpack把模塊(s)連同它的依賴一塊兒打包生成包含這些模塊的靜態資源。

爲何另用一個打包器？

現有的模塊打包器不適合大項目（大單頁面應用）程序。代碼分割和靜態資源無縫模塊化的迫切需求，催生了一個新的模塊打包器。
我試圖擴展示有的模塊打包器，可是它沒能實現全部的目標。
目標以下：
1. 把依賴樹切分紅塊，實現按需加載。
2. 保持低初始加載時間
3. 每一個靜態資源都能是一個模塊
4. 具有把第三方庫集成爲模塊的能力
5. 具有打包器每一個部分幾乎都能本身定製的特色。
6. 適合大型項目。

webpack有什麼不一樣？

代碼分割

webpack依賴樹中有兩個依賴類型：同步和異步。異步模塊切分紅一個新的的塊。在塊樹（chunk tree）優化以後，文件會爲每一個chunk發文件。

loader

webpack能夠處理javascript自己，但loader用來將其它資源轉換爲javascript。這樣以來，全部資源都被格式化成模塊了。

智能解析

webpack有一個智能解析器，它能處理幾乎全部的第三方庫。它甚至容許你在依賴中你像這樣加表達式 require("./templates/" + name + ".jade") 。它能夠處理最多見的模塊化標準風格：CommonJS和AMD。

安裝

node.js

安裝node.js
包管理工具 npm會一塊兒裝上。

webapck

webpack 能夠用用npm 命令來裝

$ npm install webpack -g

webpack 已經全局安裝了，如今 webpack 命令可用了。

項目中使用webpack

你的項目最好也有webpack 依賴。 這樣你能夠在項目中自由決定用webpack哪一個版本而必去用全局那個webpack。
用 npm 命令添加一個 package.json文件

$ npm init

若是你不發佈npm包，Init過程當中的問題不重要，均可以忽略。
安裝webpack 並添加到package.json中：

$ npm install webpack --save-dev

版本

有兩個webpack版本可用。穩定版本和beta版。beta版 在版本字符中標記爲 -beta 。beta版本可能包含脆弱的或者實驗功能，都沒進行過多少測試。正式場景下應該用穩定版。

$ npm install webpack@1.2.x --save-dev

開發工具

若是你想用開發工具，先安裝它

$ npm install webpack-dev-server --save-dev

 

 

原文地址：http://blog.csdn.net/keliyxyz/article/details/51571386