Lecture ini membahas production workflow di Webpack. Kalau lecture sebelumnya fokus pada:

“Bagaimana membuat development workflow yang nyaman?”

maka lecture ini beralih ke:

“Kalau aplikasi sudah selesai dan mau kita deploy ke user, bagaimana Webpack menyiapkan versi production?”

Ada beberapa konsep penting di sini: development vs production, config file terpisah, mode, devtool, plugin, CleanWebpackPlugin, dan perbedaan module.rules dengan plugins.

1. Gambaran besarnya dulu

Sampai lecture sebelumnya, kita punya workflow development:

Source Code
    ↓
Webpack
    ↓
Development
    ↓
Webpack Dev Server
    ↓
Browser

Sekarang kita ingin membuat workflow production:

Source Code
    ↓
Webpack
    ↓
Production optimization
    ↓
dist/
    ↓
bundle.js
    ↓
Deploy
    ↓
User

Jadi ada dua kebutuhan yang berbeda:

DEVELOPMENT
↓
Mudah debugging
Mudah melihat error
Compile cepat
Source map tersedia
Tidak terlalu banyak optimasi

PRODUCTION
↓
Performance
Bundle kecil
Optimasi maksimal
Tidak perlu debugging
Siap di-deploy

2. Kenapa development dan production harus dibedakan?

Ini adalah konsep paling penting dari lecture.

Bayangkan kita sedang membuat sebuah rumah.

Ketika rumah masih dibangun, kita ingin:

• kabel mudah dilihat
• pipa mudah diakses
• pintu sementara boleh terbuka
• alat-alat tukang masih ada
• struktur mudah diperiksa

Itulah development.

Tetapi ketika rumah sudah selesai dan akan ditempati:

• alat tukang dibuang
• bagian yang tidak diperlukan dibersihkan
• semuanya dirapikan
• rumah siap digunakan

Itulah production.

Begitu juga dengan aplikasi.

3. Development mode

Sebelumnya kita menggunakan:

mode: "development"

Tujuannya adalah membuat pengalaman developer lebih nyaman.

Webpack tidak terlalu agresif melakukan optimasi.

Misalnya dalam development kita masih ingin melihat:

const user = new User();
console.log(user);

dengan struktur kode yang relatif mudah dipahami.

Kita juga ingin source map supaya browser DevTools bisa menunjuk kembali ke:

app.ts
user.ts
user-action.ts

bukan hanya menunjukkan:

bundle.js

4. Production mode

Kalau aplikasi sudah selesai:

mode: "production"

Webpack akan lebih fokus pada:

membuat hasil akhir yang efisien untuk user.

Misalnya source code kita:

const user = new User();
console.log(user);

Dalam hasil production, Webpack bisa melakukan berbagai optimasi seperti:

• minification
• mengurangi whitespace
• mengurangi ukuran bundle
• optimization lainnya
• tree shaking dalam kondisi yang sesuai

Tujuannya:

bundle lebih kecil
       ↓
transfer lebih sedikit
       ↓
loading lebih cepat
       ↓
performance lebih baik

5. Kenapa tidak memakai satu webpack.config.js saja?

Lecture mengambil pendekatan:

webpack.config.js
       ↓
development

webpack.config.prod.js
       ↓
production

Kenapa?

Karena konfigurasi development dan production punya kebutuhan berbeda.

Misalnya development:

mode: "development"

sedangkan production:

mode: "production"

Development mungkin membutuhkan:

devtool: "inline-source-map"

sedangkan production bisa:

devtool: "none"

Development juga membutuhkan:

devServer: {
   ...
}

sedangkan production tidak membutuhkan development server.

Jadi kita bisa memisahkannya.

6. Nama config production boleh apa saja

Lecture mengatakan bahwa file production config bisa diberi nama apa saja.

Misalnya:

webpack.config.prod.js

atau:

webpack.production.js

atau:

webpack.config.production.js

Webpack tidak akan otomatis tahu bahwa file tersebut adalah config production hanya berdasarkan namanya.

Kita harus memberi tahu Webpack secara eksplisit.

Misalnya:

webpack --config webpack.config.prod.js

7. Contoh struktur project

Misalnya:

project/
│
├── src/
│   ├── app.ts
│   ├── models/
│   │   └── user.ts
│   └── user-utils/
│       └── user-action.ts
│
├── dist/
│   └── bundle.js
│
├── index.html
├── style.css
│
├── webpack.config.js
├── webpack.config.prod.js
├── package.json
├── tsconfig.json
└── node_modules/

Kita punya dua konfigurasi:

webpack.config.js
       ↓
development

webpack.config.prod.js
       ↓
production

8. Production config berasal dari config sebelumnya

Lecture kemudian melakukan:

copy konfigurasi development → paste ke production config → ubah bagian yang diperlukan.

Ini adalah pendekatan yang mudah untuk belajar.

Misalnya development:

module.exports = {
  mode: "development",

  entry: "./src/app.ts",

  output: {
    filename: "bundle.js",
    path: path.resolve(__dirname, "dist"),
    publicPath: "/dist/"
  },

  // ...
};

Production bisa dimulai dari sana.

9. Perubahan pertama: mode

Development:

mode: "development"

Production:

mode: "production"

Ini memberi tahu Webpack:

“Sekarang saya sedang membuat build yang akan digunakan untuk production.”

10. Perubahan kedua: publicPath

Pada development sebelumnya kita punya:

publicPath: "/dist/"

Lecture menghapusnya dari production config.

Kenapa?

Karena pada development, kita berurusan dengan Webpack Dev Server dan bundle yang disediakan dari memory.

Sedangkan pada production:

Webpack
   ↓
bundle.js
   ↓
ditulis ke disk
   ↓
dist/

Jadi workflow-nya berbeda.

11. Perubahan ketiga: devtool

Development sebelumnya:

devtool: "inline-source-map"

Source map sangat berguna untuk debugging.

Misalnya browser sebenarnya menjalankan:

bundle.js

Tetapi ketika error terjadi, kita ingin DevTools mengatakan:

app.ts line 15

bukan:

bundle.js line 1

Itulah kegunaan source map.

12. Kenapa production tidak menggunakan source map?

Lecture mengubah:

devtool: "inline-source-map"

menjadi:

devtool: "none"

atau pada praktiknya bisa juga menghilangkan konfigurasi devtool sesuai kebutuhan.

Alasannya:

Production tidak memprioritaskan debugging internal developer.

Source map dapat menambah ukuran output dan bisa mengekspos struktur/source code kepada pihak yang dapat mengakses sourcemap.

Catatan penting: dalam project production nyata, source map tidak selalu harus dimatikan. Banyak tim tetap menghasilkan source map untuk debugging production secara internal, tetapi tidak selalu menyajikannya secara publik. Lecture memilih none sebagai pendekatan sederhana.

13. Sekarang kita masuk ke konsep baru: Plugin

Lecture kemudian mengatakan:

kita akan menambahkan plugins.

Contohnya:

plugins: [
   ...
]

Nah, ini konsep yang sangat penting.

Webpack memiliki:

module: {
  rules: [...]
}

dan:

plugins: [...]

Keduanya berbeda.

14. module.rules vs plugins

Ini salah satu hal yang wajib kamu pahami.

module.rules

Digunakan untuk menentukan:

Bagaimana file tertentu diproses?

Contohnya:

module: {
  rules: [
    {
      test: /\.ts$/,
      use: "ts-loader"
    }
  ]
}

Artinya:

Kalau file .ts
       ↓
gunakan ts-loader

Jadi rule berlaku berdasarkan jenis file.

15. Contoh kalau kita punya CSS

Misalnya:

module: {
  rules: [
    {
      test: /\.ts$/,
      use: "ts-loader"
    },

    {
      test: /\.css$/,
      use: ["style-loader", "css-loader"]
    }
  ]
}

Maka:

.ts
 ↓
ts-loader

.css
 ↓
css-loader / style-loader

Jadi rules sifatnya seperti:

“Kalau ketemu file jenis ini, lakukan ini.”

16. Sedangkan plugins berbeda

Plugin lebih bersifat global terhadap proses Webpack.

Misalnya:

plugins: [
  new CleanWebpackPlugin()
]

Plugin tersebut tidak mengatakan:

“Kalau ketemu file .ts, lakukan sesuatu.”

Tetapi lebih seperti:

“Dalam keseluruhan proses Webpack, lakukan tugas tambahan ini.”

Jadi mental modelnya:

MODULE RULES
↓
mengatur bagaimana file diproses

PLUGINS
↓
mengatur / memperluas keseluruhan proses Webpack

17. Analogi sederhana

Bayangkan Webpack seperti sebuah pabrik.

module.rules

Adalah mesin-mesin di jalur produksi.

Barang A → mesin A
Barang B → mesin B
Barang C → mesin C

Misalnya:

.ts → ts-loader
.css → css-loader
.png → asset loader

plugins

Adalah supervisor atau alat tambahan yang bisa melakukan pekerjaan terhadap keseluruhan pabrik.

Misalnya:

sebelum produksi → bersihkan gudang
setelah produksi → buat laporan
saat produksi → optimasi sesuatu

Jadi plugin tidak terbatas pada satu jenis file.

18. Plugin yang digunakan: clean-webpack-plugin

Lecture ingin melakukan sesuatu yang sederhana tetapi penting:

hapus isi folder dist sebelum membuat build baru.

Misalnya saat ini:

dist/
├── bundle.js
├── old-file.js
├── something.js

Kita melakukan build baru.

Kita tidak ingin file-file lama masih tertinggal.

Idealnya:

dist/
├── bundle.js

hanya berisi hasil build terbaru.

19. Kenapa file lama harus dibersihkan?

Bayangkan sebelumnya project memiliki:

src/
├── app.ts
├── user.ts
└── admin.ts

Webpack menghasilkan:

dist/
├── bundle.js
├── admin.js
└── something.js

Kemudian kita mengubah struktur project.

Misalnya admin.ts dihapus.

Kalau file lama tidak dibersihkan, bisa saja:

dist/
├── bundle.js
├── admin.js       ← sudah tidak dibutuhkan
└── something.js   ← file lama

Akibatnya folder hasil build bisa berisi artefak lama.

Maka kita ingin:

build dimulai
   ↓
bersihkan dist
   ↓
buat output baru

20. Install clean-webpack-plugin

Lecture menjalankan:

npm install --save-dev clean-webpack-plugin

Perhatikan:

--save-dev

Artinya plugin tersebut merupakan development dependency.

Walaupun plugin digunakan untuk membuat production build, package ini adalah alat yang digunakan saat proses development/build, bukan library yang harus dikirim ke browser.

21. package.json akan berubah

Setelah install, kira-kira:

"devDependencies": {
  "clean-webpack-plugin": "...",
  "ts-loader": "...",
  "typescript": "...",
  "webpack": "...",
  "webpack-cli": "...",
  "webpack-dev-server": "..."
}

Versinya tergantung versi package saat project dibuat.

22. Import/requires plugin

Karena webpack.config.prod.js dijalankan oleh Node.js, kita menggunakan:

const { CleanWebpackPlugin } = require("clean-webpack-plugin");

Ini menghasilkan variable:

CleanWebpackPlugin

yang nantinya kita gunakan untuk membuat instance plugin.

23. Membuat instance plugin

Kemudian:

plugins: [
  new CleanWebpackPlugin()
]

Ini berarti:

“Gunakan CleanWebpackPlugin dalam proses Webpack.”

Kenapa ada:

new

?

Karena CleanWebpackPlugin adalah class/constructor yang perlu dibuat menjadi sebuah instance plugin.

Mental model:

CleanWebpackPlugin
       ↓
     class
       ↓
new CleanWebpackPlugin()
       ↓
instance
       ↓
Webpack menggunakan plugin tersebut

24. Error pertama di lecture: not a Constructor

Lecture sempat mengalami error:

clean plugin is not a Constructor

Ini terjadi karena ada kesalahan penamaan variable.

Misalnya mereka membuat:

const cleanPlugin = require("clean-webpack-plugin");

tetapi kemudian menulis:

new CleanPlugin()

Perhatikan:

cleanPlugin
     ↑
c kecil

CleanPlugin
↑
C besar

JavaScript bersifat case-sensitive.

Artinya:

cleanPlugin

dan:

CleanPlugin

adalah dua identifier yang berbeda.

25. Case-sensitive itu penting

Contoh:

const user = {};

Tidak sama dengan:

const User = {};

Begitu pula:

cleanPlugin

tidak sama dengan:

CleanPlugin

Jadi ketika muncul error seperti:

is not a constructor

salah satu hal yang perlu dicek adalah:

Apakah nama class/function yang kita panggil benar-benar sama dengan yang kita import?

26. Error kedua: plugin vs plugins

Lecture kemudian mendapatkan error:

configuration has an unknown property 'plugin'

Masalahnya sederhana.

Mereka menulis:

plugin: [...]

Padahal Webpack mengharapkan:

plugins: [...]

Ada huruf:

s

di belakang.

Yang benar:

plugins: [
  new CleanWebpackPlugin()
]

27. Kenapa error seperti ini bisa terjadi?

Karena webpack.config.js bukan sekadar file konfigurasi pasif.

Webpack membaca object JavaScript tersebut dan memvalidasi:

“Apakah property yang diberikan memang dikenal oleh Webpack?”

Misalnya:

module: {}

valid.

output: {}

valid.

plugins: []

valid.

Tetapi:

plugin: []

tidak sesuai schema konfigurasi Webpack.

28. Error ketiga: masalah devtool

Lecture kemudian mendapatkan error terkait:

inline hidden eval

Kemudian devtool dihapus.

Untuk memahami ini, ingat bahwa devtool memiliki banyak pilihan konfigurasi source map.

Development bisa menggunakan:

devtool: "inline-source-map"

Tetapi production tidak harus menggunakan konfigurasi tersebut.

Lecture akhirnya memilih tidak menggunakan devtool di production.

Jadi kira-kira:

// development
devtool: "inline-source-map"

sedangkan:

// production
// devtool tidak diperlukan

29. Production config akhirnya berhasil

Setelah error diperbaiki, Webpack menghasilkan:

compiled successfully

Kemudian kita melihat:

dist/
└── bundle.js

Inilah hasil yang ingin kita deploy.

30. Apa yang ada di bundle.js?

Ingat project kita menggunakan TypeScript:

src/
├── app.ts
├── models/
│   └── user.ts
└── user-utils/
    └── user-action.ts

Browser tidak menjalankan TypeScript secara langsung.

Webpack + ts-loader melakukan proses:

app.ts
user.ts
user-action.ts
       ↓
TypeScript compilation
       ↓
JavaScript
       ↓
Webpack bundling
       ↓
bundle.js

Jadi bundle.js berisi hasil JavaScript yang sudah diproses dan dibundling.

31. Kenapa cukup deploy bundle.js?

Karena dependency JavaScript yang dibutuhkan sudah dikumpulkan oleh Webpack.

Misalnya:

app.ts
   ↓
user-action.ts
   ↓
user.ts

Setelah dibundle:

bundle.js

Jadi browser tidak perlu memahami:

app.ts
user-action.ts
user.ts

secara langsung.

Browser cukup menjalankan:

bundle.js

32. Tapi jangan salah memahami “deploy source folder”

Lecture mengatakan kurang lebih bahwa kita akan deploy project tanpa node_modules.

Hal yang perlu diluruskan:

Untuk deployment website biasa, kita tidak perlu meng-upload source TypeScript dan file development ke web server hanya agar browser menjalankan aplikasi.

Biasanya workflow-nya:

Source project
   ↓
npm install
   ↓
Webpack build
   ↓
dist/
   ↓
deploy hasil build

Yang benar-benar disajikan ke browser biasanya adalah build artifacts, misalnya:

dist/
├── bundle.js
├── index.html
├── style.css
└── assets/

Tidak perlu mengirim:

node_modules/

ke browser.

Dan tidak perlu mengirim seluruh source .ts hanya agar aplikasi berjalan.

33. node_modules tidak perlu dideploy ke browser

Ini juga penting.

node_modules berisi package yang dibutuhkan selama proses development/build, misalnya:

webpack
typescript
ts-loader
clean-webpack-plugin

Browser tidak perlu menerima:

node_modules/

Browser hanya membutuhkan hasil akhirnya.

Jadi:

Developer machine

src/
package.json
node_modules/
webpack.config...
      ↓
    BUILD
      ↓
dist/
      ↓
Deployment
      ↓
Browser

34. Bedakan “source project” dan “production artifacts”

Ini mental model yang bagus.

Source/development

src/
├── app.ts
├── user.ts
└── user-action.ts

webpack.config.js
webpack.config.prod.js
tsconfig.json
package.json
node_modules/

Ini untuk developer.

Production output

Misalnya:

dist/
├── bundle.js
├── index.html
├── style.css
└── assets/

Ini untuk deployment.

35. npm run build sekarang melakukan apa?

Lecture mengubah script:

"build": "webpack --config webpack.config.prod.js"

Jadi ketika kita menjalankan:

npm run build

npm akan menjalankan:

webpack --config webpack.config.prod.js

Artinya:

“Webpack, gunakan file konfigurasi production ini.”

36. Kenapa harus --config?

Karena kita tidak lagi ingin menggunakan config default.

Biasanya Webpack akan mencari:

webpack.config.js

Tetapi kita ingin:

webpack.config.prod.js

Maka:

webpack --config webpack.config.prod.js

secara eksplisit memberitahu:

“Gunakan config yang ini.”

37. Workflow akhirnya

Sekarang project kita punya dua workflow.

Development

npm start

yang menjalankan:

webpack serve

Kemudian:

source
   ↓
Webpack
   ↓
memory
   ↓
Dev Server
   ↓
browser

Production

npm run build

yang menjalankan:

webpack --config webpack.config.prod.js

Kemudian:

source
   ↓
Webpack
   ↓
optimization
   ↓
dist/
   ↓
bundle.js
   ↓
deploy

38. Perbandingan lengkap

39. Bagaimana CleanWebpackPlugin masuk ke workflow?

Sekarang alurnya:

npm run build
      ↓
webpack --config webpack.config.prod.js
      ↓
baca production config
      ↓
CleanWebpackPlugin
      ↓
bersihkan dist
      ↓
Webpack memproses source
      ↓
TypeScript → JavaScript
      ↓
bundle
      ↓
dist/bundle.js

Jadi setiap kali production build dibuat, kita mendapatkan output yang bersih.

40. Kenapa plugin ini berguna?

Misalnya build pertama:

dist/
├── bundle.js
├── admin.js
└── user.js

Kemudian project berubah.

Build kedua sebenarnya hanya menghasilkan:

bundle.js

Tanpa clean plugin:

dist/
├── bundle.js
├── admin.js   ← file lama
└── user.js    ← file lama

Dengan clean plugin:

hapus isi dist
       ↓
Webpack build
       ↓
dist/
└── bundle.js

Lebih aman dan rapi.

41. Jangan menganggap production = sekadar mode: production

Ini juga penting.

mode: "production" memang mengaktifkan berbagai optimasi bawaan Webpack.

Tetapi production workflow yang baik biasanya juga melibatkan:

production config
+
asset handling
+
environment variables
+
source map strategy
+
HTML generation
+
CSS optimization
+
code splitting
+
caching
+
deployment configuration

Lecture ini baru memberikan high-level overview, bukan production configuration lengkap untuk semua kebutuhan.

42. Ada satu hal yang perlu dikoreksi dari cara lecture menjelaskannya

Lecture mengatakan development mode:

bundle tidak dibuat di disk dan dibuat di memory.

Secara konteks Webpack Dev Server, ini benar sebagai mental model.

Tetapi jangan mengartikan:

“mode: development selalu berarti bundle tidak pernah ditulis ke disk.”

Yang menentukan perilaku tersebut terutama adalah cara kita menjalankan Webpack, khususnya Dev Server dan konfigurasi output filesystem.

Jadi:

mode: development

dan:

bundle disimpan di memory

adalah dua konsep yang berbeda.

Yang lebih tepat:

Webpack Dev Server
→ biasanya melayani bundle dari memory

Sedangkan:

Webpack build biasa
→ menghasilkan output ke filesystem

43. Mental model besar dari seluruh section Webpack

Setelah beberapa lecture terakhir, sebenarnya kita sudah bisa melihat gambaran Webpack secara lengkap.

                 SOURCE
                   │
                   ↓
             TypeScript files
                   │
                   ↓
              ┌───────────┐
              │  Webpack  │
              └─────┬─────┘
                    │
        ┌───────────┴───────────┐
        │                       │
   DEVELOPMENT              PRODUCTION
        │                       │
        ↓                       ↓
 mode development         mode production
        │                       │
        ↓                       ↓
 Dev Server                Optimization
        │                       │
        ↓                       ↓
   Memory                  dist/bundle.js
        │                       │
        ↓                       ↓
    Browser                  Deploy

44. Cara mengingat rules dan plugins

Gunakan kalimat ini:

Rules = “Kalau ketemu file ini, harus diapakan?”

Contoh:

{
  test: /\.ts$/,
  use: "ts-loader"
}

Artinya:

Kalau .ts, proses dengan ts-loader.

Sedangkan:

Plugins = “Ada pekerjaan tambahan apa yang harus dilakukan Webpack secara keseluruhan?”

Contoh:

new CleanWebpackPlugin()

Artinya:

Bersihkan output sebelum build baru.

45. Cara mengingat development dan production

Gunakan:

DEVELOPMENT
= nyaman untuk DEVELOPER

PRODUCTION
= optimal untuk USER

Atau:

Development → Debug
Production  → Performance

46. Cara mengingat dua config

webpack.config.js
       ↓
npm start
       ↓
development

dan:

webpack.config.prod.js
       ↓
npm run build
       ↓
production

Jadi:

START → DEVELOPMENT

BUILD → PRODUCTION

Ini bukan aturan universal Webpack, tetapi workflow yang sedang dibuat dalam lecture.

47. Ringkasan semua istilah baru

🧠 Inti lecture dalam satu diagram

                 DEVELOPMENT
                      │
                 npm start
                      │
                      ↓
              webpack serve
                      │
                      ↓
              mode: development
                      │
                      ↓
             bundle di memory
                      │
                      ↓
                   Browser


                 PRODUCTION
                      │
              npm run build
                      │
                      ↓
        webpack --config webpack.config.prod.js
                      │
                      ↓
              mode: production
                      │
                      ↓
             CleanWebpackPlugin
                      │
                      ↓
                Optimization
                      │
                      ↓
               dist/bundle.js
                      │
                      ↓
                   Deploy

🎯 Kalau hanya mengingat 7 hal dari lecture ini

1. Development dan production memiliki tujuan berbeda.
2. mode: "development" → developer-friendly.
3. mode: "production" → optimization/performance.
4. npm start → menjalankan development server.
5. npm run build → membuat production build.
6. module.rules → memproses jenis file tertentu.
7. plugins → menambahkan pekerjaan/fitur pada workflow Webpack secara umum.

Dan plugin yang dipelajari di lecture ini:

new CleanWebpackPlugin()

fungsinya sederhana:

“Sebelum membuat build baru, bersihkan hasil build lama supaya folder dist hanya berisi output terbaru.”

Dengan begitu, sekarang kita sudah punya mental model yang cukup lengkap:

ES Modules
    ↓
Webpack
    ├── Development → Dev Server → Browser
    │
    └── Production → Optimization → dist → Deploy

Ini adalah inti dari production workflow dengan Webpack.