Modules and Bundling

As applications grow, putting all your code in one file becomes unmanageable. Modules let you split code into separate files, each with its own scope, and then import only what you need. In this lesson you will learn the ES module system that is now the standard for JavaScript everywhere, from browsers to servers.

What You'll Learn

Why modules matter for code organization
ES module syntax: import and export
Default exports vs named exports
Dynamic imports for code splitting
Module patterns and best practices

Why Modules?

Before modules, all JavaScript files shared the global scope. This caused naming collisions, made dependencies unclear, and made large codebases difficult to maintain. Modules solve these problems:

// The problem: global scope pollution
// Imagine these were separate script files loaded on a page

// file1.js
var name = "Alice";
var count = 10;

// file2.js (loaded later, overwrites file1's variables!)
var name = "Bob";
var count = 20;

console.log(name);  // "Bob" - file1's name is gone!
console.log(count); // 20 - file1's count is gone!

// With modules, each file has its own scope
// No variables leak out unless explicitly exported
console.log("\nWith modules, each file is isolated:");
console.log("- file1.js exports: { name: 'Alice', count: 10 }");
console.log("- file2.js exports: { name: 'Bob', count: 20 }");
console.log("- No conflicts because each module has its own scope");

Named Exports

Named exports let you export multiple values from a module. The importing code must use the exact same names (or rename them explicitly):

// Simulating a math utilities module
// In a real file: mathUtils.js

// Named exports (would use 'export' keyword in a real module)
const PI = 3.14159;

function add(a, b) {
  return a + b;
}

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

function square(n) {
  return n * n;
}

// Simulating: export { PI, add, multiply, square };
const mathUtils = { PI, add, multiply, square };

// Simulating: import { add, multiply, PI } from './mathUtils.js';
const { add: importedAdd, multiply: importedMultiply, PI: importedPI } = mathUtils;

console.log("PI:", importedPI);
console.log("add(5, 3):", importedAdd(5, 3));
console.log("multiply(4, 6):", importedMultiply(4, 6));

// Simulating: import * as math from './mathUtils.js';
const math = mathUtils;
console.log("\nUsing namespace import:");
console.log("math.square(9):", math.square(9));
console.log("math.PI:", math.PI);

// Real module syntax reference:
console.log("\n--- Real syntax ---");
console.log("export const PI = 3.14159;");
console.log("export function add(a, b) { return a + b; }");
console.log('import { add, PI } from "./mathUtils.js";');
console.log('import * as math from "./mathUtils.js";');

Default Exports

Each module can have one default export. Default exports are convenient when a module's primary purpose is to export a single thing, like a class or a main function:

// Simulating default and named exports

// userService.js - default export is the class
function UserService(apiUrl) {
  this.apiUrl = apiUrl;
  this.users = [];
}

UserService.prototype.addUser = function(name, email) {
  const user = { id: this.users.length + 1, name, email };
  this.users.push(user);
  return user;
};

UserService.prototype.findUser = function(id) {
  return this.users.find(function(u) { return u.id === id; });
};

UserService.prototype.listUsers = function() {
  return this.users;
};

// Also export a helper (named export)
function formatUser(user) {
  return user.name + " <" + user.email + ">";
}

// Simulating: export default UserService;
// Simulating: export { formatUser };

// When importing a default, you can name it anything
// import UserService from './userService.js';
// import { formatUser } from './userService.js';
// import UserService, { formatUser } from './userService.js';

const service = new UserService("https://api.example.com");
service.addUser("Alice", "alice@example.com");
service.addUser("Bob", "bob@example.com");

console.log("All users:", service.listUsers());
console.log("User 1:", formatUser(service.findUser(1)));
console.log("User 2:", formatUser(service.findUser(2)));

console.log("\n--- Real syntax ---");
console.log("export default class UserService { ... }");
console.log("export function formatUser(user) { ... }");
console.log('import UserService from "./userService.js";');
console.log('import UserService, { formatUser } from "./userService.js";');

Re-exports and Barrel Files

Large projects use barrel files (usually named index.js) to re-export items from multiple modules, creating a clean public API:

// Simulating a barrel file pattern

// models/user.js
const User = { type: "User", fields: ["name", "email"] };

// models/product.js
const Product = { type: "Product", fields: ["name", "price"] };

// models/order.js
const Order = { type: "Order", fields: ["userId", "productIds", "total"] };

// models/index.js (barrel file) - re-exports everything
// export { User } from './user.js';
// export { Product } from './product.js';
// export { Order } from './order.js';
const models = { User, Product, Order };

// Now consumers import from one place
// import { User, Product, Order } from './models';
// instead of:
// import { User } from './models/user';
// import { Product } from './models/product';
// import { Order } from './models/order';

console.log("Barrel file exports:");
Object.keys(models).forEach(function(key) {
  console.log("  " + models[key].type + ": " + models[key].fields.join(", "));
});

console.log("\n--- Real barrel file syntax ---");
console.log("// models/index.js");
console.log('export { User } from "./user.js";');
console.log('export { Product } from "./product.js";');
console.log('export { Order } from "./order.js";');
console.log("");
console.log("// consumer.js");
console.log('import { User, Product, Order } from "./models";');

Dynamic Imports

Static imports are loaded at the top of a file before any code runs. Dynamic imports load modules on demand, which is essential for performance because users only download code when they need it:

// Simulating dynamic imports
// In real code: const module = await import('./heavyModule.js')

function simulateImport(moduleName, delay) {
  return new Promise(function(resolve) {
    console.log("Loading " + moduleName + "...");
    setTimeout(function() {
      const fakeModule = {
        name: moduleName,
        default: function() { return moduleName + " is ready"; },
        version: "1.0.0"
      };
      console.log(moduleName + " loaded!");
      resolve(fakeModule);
    }, delay);
  });
}

// Load modules on demand (like clicking a button)
async function loadFeature(featureName) {
  try {
    const module = await simulateImport(featureName, 500);
    console.log("Result:", module.default());
    console.log("Version:", module.version);
  } catch (error) {
    console.log("Failed to load:", error.message);
  }
}

async function main() {
  console.log("App started - only core modules loaded\n");

  // These would be triggered by user actions
  await loadFeature("ChartLibrary");
  console.log("");
  await loadFeature("PDFExporter");

  console.log("\n--- Real dynamic import syntax ---");
  console.log('const { Chart } = await import("./charts.js");');
  console.log('const module = await import(`./features/${name}.js`);');
}

main();

Module Design Patterns

Well-designed modules follow certain patterns that make them easy to use, test, and maintain:

// Pattern 1: Single Responsibility
// Each module does one thing well

const Logger = (function() {
  const logs = [];

  return {
    info(message) { logs.push({ level: "INFO", message, time: Date.now() }); console.log("[INFO] " + message); },
    warn(message) { logs.push({ level: "WARN", message, time: Date.now() }); console.log("[WARN] " + message); },
    error(message) { logs.push({ level: "ERROR", message, time: Date.now() }); console.log("[ERROR] " + message); },
    getHistory() { return [...logs]; }
  };
})();

// Pattern 2: Factory Functions
// Export functions that create configured instances

function createValidator(rules) {
  return {
    validate(data) {
      const errors = [];
      rules.forEach(function(rule) {
        if (!rule.test(data[rule.field])) {
          errors.push(rule.field + ": " + rule.message);
        }
      });
      return { valid: errors.length === 0, errors };
    }
  };
}

// Pattern 3: Constants Module
// Centralize configuration

const CONFIG = Object.freeze({
  API_URL: "https://api.example.com",
  MAX_RETRIES: 3,
  TIMEOUT: 5000,
  ITEMS_PER_PAGE: 20
});

// Using the modules together
Logger.info("Starting application");
Logger.info("API URL: " + CONFIG.API_URL);

const emailValidator = createValidator([
  { field: "email", test: function(v) { return v && v.includes("@"); }, message: "Must be valid email" },
  { field: "name", test: function(v) { return v && v.length >= 2; }, message: "Must be at least 2 chars" }
]);

const result = emailValidator.validate({ email: "test@test.com", name: "Al" });
if (result.valid) {
  Logger.info("Validation passed");
} else {
  result.errors.forEach(function(e) { Logger.warn(e); });
}

console.log("\nLog history:", Logger.getHistory().length, "entries");

Try It Yourself

Design a modular shopping system with separate concerns:

// Simulating a modular e-commerce system

// Module 1: Product catalog
const Catalog = (function() {
  const products = [
    { id: 1, name: "Laptop", price: 999, stock: 5 },
    { id: 2, name: "Mouse", price: 29, stock: 50 },
    { id: 3, name: "Keyboard", price: 79, stock: 30 },
    { id: 4, name: "Monitor", price: 449, stock: 10 }
  ];

  return {
    getAll() { return [...products]; },
    findById(id) { return products.find(function(p) { return p.id === id; }); },
    checkStock(id) {
      const product = this.findById(id);
      return product ? product.stock : 0;
    }
  };
})();

// Module 2: Cart
const Cart = (function() {
  const items = [];

  return {
    add(productId, quantity) {
      quantity = quantity || 1;
      const product = Catalog.findById(productId);
      if (!product) { console.log("Product not found"); return; }
      if (Catalog.checkStock(productId) < quantity) { console.log("Not enough stock"); return; }

      const existing = items.find(function(i) { return i.productId === productId; });
      if (existing) {
        existing.quantity += quantity;
      } else {
        items.push({ productId, name: product.name, price: product.price, quantity });
      }
      console.log("Added " + quantity + "x " + product.name + " to cart");
    },

    getTotal() {
      return items.reduce(function(sum, item) { return sum + item.price * item.quantity; }, 0);
    },

    summary() {
      console.log("\nCart Summary:");
      items.forEach(function(item) {
        console.log("  " + item.name + " x" + item.quantity + " = $" + (item.price * item.quantity));
      });
      console.log("  Total: $" + this.getTotal());
    }
  };
})();

// Using the modules
console.log("Available products:");
Catalog.getAll().forEach(function(p) {
  console.log("  " + p.name + " - $" + p.price + " (" + p.stock + " in stock)");
});

Cart.add(1, 1);
Cart.add(2, 2);
Cart.add(3, 1);
Cart.summary();

Key Takeaways

Modules give each file its own scope, preventing global variable conflicts
Named exports let you export multiple values; default exports are for one main value per module
Use import { name } from './module' for named exports and import Name from './module' for defaults
Barrel files re-export from multiple modules for a clean public API
Dynamic imports with await import() load code on demand for better performance
Good module design follows single responsibility and creates clear public interfaces

Next Steps

Now that you can organize code into modules, the next lesson covers testing and debugging. You will learn how to verify your modules work correctly and track down bugs efficiently.

Pro Tip: Keep modules small and focused. If a module is doing too many things, split it up. A good rule of thumb: if you cannot describe what a module does in one sentence, it probably needs to be broken into smaller pieces.