Modules, Tooling, and First Tests

Why it matters

Every real program eventually outgrows a single file. Modules are how JavaScript splits code into manageable, independently reasoned-about pieces; package.json and a lockfile are how a project records what it depends on so it builds the same way for every contributor; and a first test is how you check a function keeps working as the rest of the program changes around it.

Modules: export and import

A module is a single file with its own scope — nothing inside it is visible elsewhere unless explicitly exported, and nothing from another module is visible unless explicitly imported:

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

export const PI_ROUNDED = 3.14;

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

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

console.log(add(2, 3)); // 5
console.log(multiply(2, 3)); // 6
console.log(PI_ROUNDED); // 3.14

A module can have any number of named exports (export function, export const, imported with { }), but at most one default export (imported without { }, and can be given any local name).

package.json and dependencies

package.json describes a Node project: its name, its scripts, and what it depends on.

{
  "name": "my-app",
  "type": "module",
  "scripts": {
    "start": "node index.js",
    "test": "vitest run"
  },
  "dependencies": {
    "some-library": "^2.1.0"
  },
  "devDependencies": {
    "vitest": "^4.0.0"
  }
}

Running npm install some-library adds it to dependencies; npm install --save-dev vitest adds it to devDependencies. The scripts object defines named commands runnable with npm run scriptName (a few conventional names, like start and test, can be run without run).

Why the lockfile matters

npm install also writes (or updates) package-lock.json — recording the exact version of every dependency, and every dependency of those dependencies, that was actually installed. package.json’s version ranges (^2.1.0) allow some flexibility; the lockfile pins an exact, reproducible set.

A first unit test

A unit test checks one small piece of behavior — often a single pure function — in isolation. The Arrange/Act/Assert structure keeps a test’s intent clear: set up the input, run the code under test, check the result.

import { describe, it, expect } from 'vitest';
import { calculateDiscount } from './pricing.js';

describe('calculateDiscount', () => {
  it('applies a percentage discount to a price', () => {
    // Arrange
    const price = 100;
    const percentOff = 20;

    // Act
    const result = calculateDiscount(price, percentOff);

    // Assert
    expect(result).toBe(80);
  });

  it('returns the original price when percentOff is 0', () => {
    // Arrange / Act
    const result = calculateDiscount(50, 0);

    // Assert — a boundary case, not just the typical one
    expect(result).toBe(50);
  });
});

Testing 0 alongside a typical value above is deliberate — a boundary case (an edge of the input range: zero, empty, the maximum, the minimum) is exactly where off-by-one and edge-case bugs tend to hide, and where “looks right for the obvious case” tests provide the least protection.

Check your understanding

Practice: warm-up

Given a file strings.js with export function shout(text) { return text.toUpperCase() + '!'; } and no default export, write the correct import statement and a call that logs "HELLO!".

import { shout } from './strings.js';
console.log(shout('hello'));

Practice: apply it

Write a pure function clampScore(score, min, max) that returns score, clamped to the inclusive range [min, max]. Then write three Arrange/Act/Assert tests: a value inside the range, a value above max, and a value exactly equal to min (a boundary case).

export function clampScore(score, min, max) {
  return Math.min(Math.max(score, min), max);
}

import { describe, it, expect } from 'vitest';
import { clampScore } from './scoring.js';

describe('clampScore', () => {
  it('returns the score unchanged when inside the range', () => {
    expect(clampScore(50, 0, 100)).toBe(50);
  });

  it('clamps a score above the maximum', () => {
    expect(clampScore(150, 0, 100)).toBe(100);
  });

  it('keeps a score exactly at the minimum boundary', () => {
    expect(clampScore(0, 0, 100)).toBe(0);
  });
});

Summary

• A module is a file with its own scope; export/import (named or default) is how code crosses between modules deliberately.
• package.json lists a project’s scripts and dependencies; dependencies ship with the running program, devDependencies are needed only during development.
• package.json’s version ranges allow flexibility; the committed lockfile pins exact, reproducible versions — both are needed for a build to be reliably reproducible across contributors and CI.
• A unit test checks one small piece of behavior in isolation, structured as Arrange (set up), Act (run the code), Assert (check the result).
• Testing boundary cases (zero, empty, the minimum, the maximum) catches the class of bug that a test of only the “obvious” case would miss.