TypeScript Modules

One program, several files

A module is a file that exports names and imports names from other files. You writeexport on a function, a class, a type, or a constant when other files should see it. You writeimport in the file that uses it. The compiler checks that the names and types line up across that boundary.

C++ splits work with headers and .cpp files. TypeScript splits work with .ts modules. The idea is the same: keep a helper next to its types, then reuse it without copy-paste. StudyGrid’s editor at/typescript/try still compiles one buffer. Locally you save two files and let tsc follow the imports.

What the editor can still run

This program is a complete TypeScript file. The helper and the calls live together. Copy it into/typescript/try, change the arguments, and compile again. There is no second file to load.

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

console.log(square(5));
console.log(square(12));

Output is 25 then 144. That is the function you would export once it lives in its own file. Until then, a plain function in the same buffer is enough to practice the body.

export function in its own file

When you are ready to split, put the helper in mathx.ts and mark it export. Only exported names are visible to importers. A function without export stays private to that file.

// mathx.ts — save locally; the editor does not load a second file
export function square(n: number): number {
  return n * n;
}

export function cube(n: number): number {
  return n * n * n;
}

The listing is a real module. Download it or paste it into a local folder. Do not expect/typescript/try to resolve mathx.ts; that page compiles the buffer you see, nothing else.

import as a local follow-up

In another file in the same project, name what you need and where it lives. The path is a string without the.ts suffix in many setups; tsc still finds mathx.ts. This is the local follow-up, not something the StudyGrid editor runs.

// main.ts — local project, next to mathx.ts
import { square, cube } from "./mathx";

console.log(square(5));
console.log(cube(3));

Output, after a local npx tsc --strict main.ts (and running the emitted JavaScript), is25 then 27. Curly braces list the exported names. The file that exports them does not run by itself unless something imports it or you compile it as an entry.

Types cross the same boundary

You can export a type or an interface the same way. The importer uses it in annotations. This one-file program shows the shape you would split: a typed helper, then calls. In a local project the type would sit next toexport function area.

type Rect = {
  width: number;
  height: number;
};

function area(r: Rect): number {
  return r.width * r.height;
}

const card: Rect = { width: 8, height: 5 };
console.log(area(card));
console.log(area({ width: 3, height: 3 }));

Output is 40 then 9. Locally you would write export type Rect andexport function area, then import { area, type Rect } from "./shapes" in the file that builds card.

What belongs in a module

• One idea per file once a helper has a stable name and type.
• Export the public surface. Leave the rest unexported.
• Prefer modules over namespaces in new TypeScript. Namespaces still appear later in this track for grouping types.

Compile locally when you split

Save mathx.ts and main.ts in one folder. Run tsc on the entry file. Node runs the JavaScript tsc emitted. The StudyGrid editor stays useful for the function body: paste the one-file version, prove the numbers, then add export and import on disk. Next: what to do when a function cannot finish — exceptions.