目錄javascript
當前 webpack 版本 : v4.18.0html
webpack -v // 4.18.0
同以前的版本不同的地方是須要 全局安裝 webpack-cli前端
webpack-cli -v // 3.1.0
思考這個 webpack-cli 是真的有用麼? 其實對於我來說感受很雞肋,雖然它是出現是爲了讓我webpack 零配置化,但就目前 webpack-cli 的體驗來說,仍是比較雞肋,在實際的開發過程當中,我仍是比較喜歡 diy ,這樣自由的折騰方式, 零配置,就意味着你要爲 高度定製化做出犧牲。vue
這讓我想起了以前面試不少前端開發的時候,其實就是一個很簡單的問題,如何搭建一個最簡單的 webpack 的開發架構,JS 壓縮一下, LESS 預編譯一下, CSS 壓縮一下。這類,不少習慣了用 vue-cli 的同窗就懵逼了,由於他們認爲 架構就是用別人的東西,但實際的開發中,出於業務需求的須要,咱們的架構須要更加多的靈活性和高度可定製化性。 因此這纔是寫這篇文章的 出發點。java
開局一張圖:node
本質上,webpack
是一個現代 JavaScript 應用程序的靜態模塊打包器
(static module bundler)。在 webpack 處理應用程序時,它會在內部建立一個依賴圖(dependency graph),用於映射到項目須要的每一個模塊,而後將全部這些依賴生成到一個或多個bundle。webpack
在開始前咱們須要先理解它的
核心概念
:git
入口起點(entry point)github
這裏是一切開始的起點。面對實際的業務來說的話,能夠分爲單頁面( SPA ) 和多頁面。那麼今天就針對這2種狀況來分別 介紹下 利用 webpack 進行項目架構的須要注意的地方。web
webpack.config.js
module.exports = { entry: './app.js' }
webpack.config.js
module.exports = { entry: { app: './app.js', vendors: './src/JQ.js' } }
webpack.config.js
module.exports = { entry: { pageOne: './src/pageOne/index.js', pageTwo: './src/pageTwo/index.js', pageThree: './src/pageThree/index.js' } };
可是這裏只是人工的去配置了多頁面,其實很明顯這種作法很不聰明。
因此你須要一個聰明的作法,這裏就大體講一下思路。 經過
( ' ./src/**/*.js' ) 匹配到 多頁面到文件入口路徑,而後 經過 glob.sync(globPath)
獲取到所有路徑,拿到每一個頁面的 入口文件路徑。 最後傳值給 webpack 的 entry 對象。
webpack.config.js
module.exports = { output: { filename: 'bundle.js', path: '/home/proj/public/assets' } };
webpack.config.js
module.exports = { output: { filename: '[name].js', path: __dirname + '/dist' } };
這裏的 loader 就像一個又一個的加工廠同樣,把你輸送給 加工產的原材料加工生成你想要的成品或者半成品。最後出廠~
有用過 gulp 相似的構建工具等同窗 就很 容易理解,這裏的一個個的 loader 就想當一一個個的 task, 這個任務完成就會交給下一我的,直到整個流水線工做跑完~
在更高層面,在 webpack 的配置中 loader 有兩個特徵(demo):
webpack.config.js
const path = require('path'); module.exports = { output: { filename: 'my-first-webpack.bundle.js' }, module: { rules: [ { test: /\.txt$/, use: 'raw-loader' } ] } }
其中有三個須要注意的地方:
一、loader 的特徵之一: test
屬性,用於標識出應該被對應的 loader 進行轉換的某個或某些文件。
二、loader 的特徵之二: use
屬性,表示進行轉換時,應該使用哪一個 loader。
三、在 webpack 配置中定義 loader 時,要定義在 module.rules
中,而不是 rules
前期這裏也只是大概的瞭解一下,在後面的文章中,咱們會手把手的教你 手寫一個 loader
這篇文章還只是教你如何使用 webpack。 敬請期待後面的文章吧 😁
插件是 webpack 的支柱
功能。webpack 自身也是構建於,你在 webpack 配置中用到的相同的插件系統之上!
插件目的在於解決 loader 沒法實現
的其餘事。
webpack.config.js
module.exports = { entry: './path/to/my/entry/file.js', output: { filename: 'my-first-webpack.bundle.js', path: path.resolve(__dirname, 'dist') }, module: { rules: [ { test: /\.(js|jsx)$/, use: 'babel-loader' } ] }, plugins: [ new HtmlWebpackPlugin({template: './src/index.html'}) ] }
同樣的,前期這裏也只是大概的瞭解一下,在後面的文章中,咱們會手把手的教你 手寫一個 plugins
這篇文章還只是教你如何使用 webpack。 敬請期待後面的文章吧 😁
在上面的文章中,咱們已經大體介紹了 webpack 的概念,下面就是須要咱們來配置一個 能夠實際使用的項目。
建立 import 或 require 的別名,來確保模塊引入變得更簡單。例如,一些位於 src/ 文件夾下的經常使用模塊:
module.exports = { //... resolve: { alias: { 'vue$': 'vue/dist/vue.common.js', 'src': path.resolve(__dirname, './src/src/'), 'assets': path.resolve(__dirname, './src/assets/'), 'components': path.resolve(__dirname, '../src/components') } } };
有了上面的配置後,在項目文件中若是須要引用 components 文件夾下面的某個組件的時候 就能夠 直接 以下的引用方式:
import Alert from 'component/alert'
這樣就能夠 忽略由於項目文件過深而引發的 引用組件路徑出錯的問題,從而加快效率。
自動解析肯定的擴展。默認值爲:
module.exports = { //... resolve: { extensions: ['.wasm', '.mjs', '.js', '.json'] } };
這樣的話,就會幫你把未加上 後綴名的文件自動加上配置後綴,從而加快開發效率。
固然也是按照你所給出的文件路徑去匹配的後綴,而不是隨意加上後綴名。
關於 resolve 解析 的內容還有不少,你們能夠參考 webpack 官方文檔去尋找本身須要的內容,讓本身開發項目的速度變得更加快捷方便。
在 4.0 之後的 webpack 版本,他們專門把 optimization 提取出來做爲一個大的模塊來進行了優化,由於這個功能實在是太能有效的提高項目的加載速度了。爲何會這麼說呢?下面咱們就來了解了解~
咱們先來看一個簡單的配置:
module.exports = { //... optimization: { minimize: false } };
這個屬性是一個 布爾類型,是告訴 webpack 咱們是否在當前環境下去壓縮混淆咱們的 JS 代碼。
固然 須要配合這個屬性來使用的還有一個 插件
主要注意: UglifyjsWebpackPlugin
這個屬性是在 webpack 4.0 + 才提供的。用來 分離切割 體積較大的 JS 文件。
而後 webpack 會自動將 通用的 chunk 進行分割,從而最大限度的作到 複用
,從而減小 main chunk 的體積。
plugins
選項用於以各類方式自定義 webpack 構建過程。webpack 附帶了各類內置插件,能夠經過webpack.[plugin-name]
訪問這些插件。
webpack 插件列表。例如,當多個 bundle 共享一些相同的依賴,CommonsChunkPlugin 有助於提取這些依賴到共享的 bundle 中,來避免重複打包。這裏仍是舉例說明:
module.exports = { //... plugins: [ new webpack.optimize.CommonsChunkPlugin({ name: 'vendor', filename: 'vendor-[hash].min.js', }) ] };
這裏 CommonsChunkPlugin 就會告訴 webpack 讓它把 多個 bundle 共享一些相同的依賴,抽離出來,造成一個單獨的 bundle 從而避免重複打包而帶來的性能損耗。
這裏的重要部分就是 webpack-dev-server 這個插件了。
webpack-dev-server 建立當前本地開發的node環境,從而纔能有上面種種 webpack 對於文件的操做權限,才能隨心所欲,這個是基本。咱們仍是來一個最簡單的 demo。
module.exports = { //... devServer: { contentBase: path.join(__dirname, 'dist'), compress: true, port: 9000 } };
這裏面也有很是多的 屬性配置,基本知足了咱們開發中遇到的大多數的問題。
基本上完成了上面文章中介紹到的內容,咱們就已經能夠完成基本的 webpack 配置的功能了, 注意: 這裏說到的是 基本的 webpack 的配置工做,那麼在咱們的實際的項目開發中,咱們會遇到的問題和須要咱們經過webpack 來解決的問題很是之多。
由於咱們須要結合一系列的框架來完成咱們的前端開發的工做,React、Vue、Angular、JQ,Backbone 等等等。 這系列的框架 風格各異,可是又萬變不離其宗,核心須要注意的地方就那麼多,下一篇文章就會 講到一個 現代 前端開發 須要注意的一個重要 插件。
Babel
。
關於 webpack 入門的文章就介紹到這裏了,歡迎一塊兒來論道~
GitHub 地址:(歡迎 star 、歡迎推薦 : )