ES Modules JavaScript: import, export, dan Pemuatan Dinamis

Module Adalah File dengan Scope Sendiri

Sebelum ES modules ada, setiap tag <script> menumpahkan variabelnya ke namespace global, dan urutan pemuatan menentukan siapa melihat apa. ES modules memperbaikinya dengan menjadikan setiap file sebagai scope tersendiri. Tidak ada yang bocor keluar kecuali kamu melakukan export secara eksplisit. Tidak ada yang masuk kecuali kamu melakukan import secara eksplisit.

Dua file, satu melakukan export, satu melakukan import:

// math.js
export function add(a, b) {
  return a + b;
}

export function multiply(a, b) {
  return a * b;
}

// main.js
import { add, multiply } from './math.js';

console.log(add(2, 3));
console.log(multiply(4, 5));

add dan multiply berada di math.js. Keduanya hanya terlihat di main.js karena ada import. Tidak ada hal lain di math.js, entah helper, konstanta, atau apa pun, yang bisa dijangkau dari luar.

Dua aturan muncul dari sini dan layak kamu pahami sejak awal:

• Module otomatis berjalan dalam strict mode. Tidak perlu 'use strict'.
• this di tingkat atas bernilai undefined, bukan objek global.

Named Export: Export Sambil Jalan

Bentuk yang paling umum. Taruh export di depan function, class, const, atau let mana pun, maka ia menjadi bagian dari permukaan publik module tersebut:

// shapes.js
export const PI = 3.14159;

export function circleArea(r) {
  return PI * r * r;
}

export class Square {
  constructor(side) {
    this.side = side;
  }
  area() {
    return this.side ** 2;
  }
}

// main.js
import { PI, circleArea, Square } from './shapes.js';

console.log(PI);
console.log(circleArea(5));
console.log(new Square(4).area());

Nama di dalam kurung kurawal harus persis sama dengan nama yang di-export. import { circlearea } akan gagal. Kalau sebuah nama bentrok dengan sesuatu yang sudah kamu punya, ganti namanya saat import dengan as:

// shapes.js
export function area(r) {
  return 3.14159 * r * r;
}

// main.js
import { area as circleArea } from './shapes.js';

console.log(circleArea(10));

Kamu juga bisa mendaftarkan export di bagian bawah file, bukan langsung di tempat. Sebagian orang lebih suka cara ini karena ada bagian "API publik" yang jelas:

// shapes.js
function area(r) {
  return 3.14159 * r * r;
}
const PI = 3.14159;

export { area, PI };

// main.js
import { area, PI } from './shapes.js';
console.log(area(PI));

Kedua gaya memberi hasil yang sama. Pilih satu dan tetap konsisten dalam satu proyek.

Default Export: Satu per Module

Sebuah module juga bisa punya satu export default. Default ditujukan untuk file yang memang punya satu hal utama, seperti sebuah komponen, class, atau objek konfigurasi:

// logger.js
export default function log(message) {
  console.log(`[log] ${message}`);
}

// main.js
import log from './logger.js';

log('server started');

Tiga hal yang perlu diperhatikan:

• Tidak ada kurung kurawal di sekitar log di sisi import.
• Nama yang di-import bebas kamu tentukan. import shout from './logger.js' akan bekerja persis sama.
• Hanya satu default export per file. Coba tambahkan yang kedua, maka file itu tidak akan bisa di-parse.

Named export dan default export bisa ada bersamaan:

// logger.js
export default function log(message) {
  console.log(`[log] ${message}`);
}

export function warn(message) {
  console.warn(`[warn] ${message}`);
}

// main.js
import log, { warn } from './logger.js';

log('booting');
warn('low disk space');

Default dulu, lalu named export di dalam kurung kurawal. Urutannya tetap.

Mana yang sebaiknya kamu pakai? Named export lebih mudah di-refactor: mengganti nama di seluruh codebase cukup dengan satu find-and-replace karena setiap import memakai nama yang sama. Default lebih fleksibel, tetapi setiap pemanggil bisa memilih nama berbeda, sehingga pencarian dengan grep jadi lebih sulit. Kebanyakan panduan gaya modern condong ke named export dan menyisakan default untuk module yang benar-benar hanya punya satu tujuan.

Import Semuanya, Re-Export, dan Efek Samping

Beberapa bentuk import lain yang akan kamu temui.

Ambil semua named export ke dalam satu objek namespace:

// shapes.js
export const PI = 3.14159;
export function area(r) { return PI * r * r; }

// main.js
import * as shapes from './shapes.js';

console.log(shapes.PI);
console.log(shapes.area(3));

Re-export dari module lain tanpa meng-import ke scope saat ini:

// index.js
export { area, PI } from './shapes.js';
export { default as log } from './logger.js';

Pola itulah cara titik masuk sebuah library mengumpulkan bagian-bagian dari file internal ke satu permukaan publik.

Dan terakhir, import tanpa binding sama sekali, untuk module yang tugasnya hanya menghasilkan efek samping (polyfill, CSS-in-JS, mendaftarkan handler):

import './polyfills.js';

File itu berjalan sekali; tidak ada yang di-import berdasarkan nama.

Import Itu Statis dan Hidup

Dua sifat import yang sesekali mengejutkan orang.

Statis. Deklarasi import diselesaikan sebelum kodemu berjalan. Kamu tidak bisa menaruhnya di dalam if, fungsi, atau try. Path-nya harus berupa string literal, bukan variabel. Itulah yang memungkinkan tools menganalisis import tanpa menjalankan kodenya: bundler, type checker, dan tree-shaker semuanya mengandalkan hal ini.

// Not allowed - SyntaxError.
if (userWantsFancy) {
  import { fancy } from './fancy.js';
}

Kalau kamu butuh pemuatan kondisional, pakai import() (dibahas berikutnya).

Hidup. Binding hasil import adalah referensi read-only ke export-nya, bukan salinan. Kalau module yang meng-export mengisi ulang nilainya, module yang meng-import melihat nilai yang baru:

// counter.js
export let count = 0;
export function increment() {
  count += 1;
}

// main.js
import { count, increment } from './counter.js';

console.log(count);
increment();
increment();
import('./counter.js').then(m => console.log(m.count));

Kamu juga tidak bisa mengisi ulang sebuah import di sisi pemakai: count = 5 di main.js akan memunculkan error. Import adalah tampilan yang read-only.

import() Dinamis untuk Memuat Sesuai Kebutuhan

Saat kamu perlu memutuskan ketika runtime apakah sebuah module dimuat, misalnya untuk fitur yang berat, code splitting berdasarkan route, atau polyfill kondisional, pakai import() sebagai fungsi. Ia mengembalikan promise yang menghasilkan export milik module tersebut:

async function loadChart() {
  const chart = await import('./chart.js');
  chart.render();
}

document.querySelector('#show-chart')?.addEventListener('click', loadChart);

Karena ini pemanggilan fungsi biasa, kamu bisa:

• Melakukan await di dalam fungsi async.
• Memberikan variabel sebagai path-nya.
• Memakainya di dalam if atau try/catch.

Destructuring pada objek hasilnya bekerja sama seperti import statis:

const { default: log, warn } = await import('./logger.js');
log('loaded dynamically');
warn('careful now');

default adalah key untuk default export saat kamu melakukan destructuring. Ganti namanya sesukamu.

Kasus penggunaan praktisnya adalah code-splitting (library chart baru dikirim saat pengguna mengklik "show chart"), polyfill berdasarkan deteksi fitur, dan plugin yang ditemukan saat runtime.

Menjalankan ES Modules: Browser dan Node

Sintaksnya sama di mana-mana; yang berbeda adalah cara runtime menemukan dan memuat file-nya.

Di browser, tandai script utamanya sebagai module:

<script type="module" src="./main.js"></script>

Dengan type="module", browser menghormati import/export, menjalankan kode dalam strict mode, dan menunda eksekusi sampai HTML selesai di-parse. Path harus relatif (./, ../) atau URL absolut. Bare specifier seperti import 'lodash' tidak berfungsi tanpa import map atau bundler.

Di Node, ada dua cara untuk mengaktifkannya:

• Beri nama file dengan ekstensi .mjs, atau
• Atur "type": "module" di package.json terdekat, yang menjadikan setiap file .js sebagai module.

Node juga mewajibkan path lengkap dengan ekstensi: import './utils.js', bukan import './utils'.

// package.json
{
  "type": "module",
  "main": "./index.js"
}

Kedua lingkungan mewajibkan ekstensi eksplisit di ESM native. Bundler (Vite, webpack, esbuild) akan menyelesaikan path tanpa ekstensi untukmu selama development. Praktis, tetapi mengandalkannya berarti source code-mu tidak akan jalan tanpa langkah build.

Jebakan Umum

Beberapa hal yang sering menjebak:

• Lupa type="module" di browser. Tanpa itu, <script> berjalan sebagai script klasik dan import menjadi syntax error.
• Ekstensi file tidak ada di Node. import './utils' gagal; import './utils.js' berhasil. Bundler menyembunyikan masalah ini, runtime native tidak.
• Mengharapkan __dirname atau require di ES module. Keduanya hanya ada di CommonJS. Di ESM, pakai import.meta.url dan ubah saat kamu butuh path.
• Import melingkar yang menyentuh nilai sebelum siap. Dua module yang saling meng-import itu sah, tetapi membaca export yang belum diisi akan memberimu undefined. Susun kodemu agar putaran itu tidak tersentuh saat inisialisasi, atau pecahlah.
• Mencoba melakukan import secara kondisional. Pernyataan import statis tidak mengizinkannya. Pakai import() dinamis untuk apa pun yang bergantung pada runtime.

Berikutnya: CommonJS vs ESM

ES modules adalah standarnya, tetapi banyak kode Node di lapangan masih memakai CommonJS, dengan require, module.exports, dan aturan yang berbeda soal kapan kode berjalan. Memahami keduanya, dan cara keduanya saling bekerja sama, adalah topik halaman berikutnya.