Organizing Code Across Files

Separate files by responsibility: domain definitions, reusable transformations, and application entry points. Public exports act as a boundary. Prefer simple imports between modules, and watch for circular dependencies when modules initialize one another.

Reading the code: Task describes the domain shape; complete returns a new object instead of mutating the input. In a multi-file project, model.ts can export Task, task-service.ts can export complete, and main.ts can coordinate them.

Keep the boundary clear: A deeply nested directory structure adds complexity without necessarily improving module boundaries. Begin with meaningful responsibilities.

Save the code as organizing-code-across-files.ts. The result below was captured after compiling this exact example with strict TypeScript checking and executing the emitted JavaScript in Node.js.

TypeScript code

export type Task = { title: string; done: boolean };
export function complete(task: Task): Task { return { ...task, done: true }; }
const task: Task = { title: "Review", done: false };
console.log(complete(task));

Verified output

{ title: 'Review', done: true }

Build: npx tsc --strict --target es2022 --module commonjs --lib es2022,dom,esnext.disposable organizing-code-across-files.ts; run: node organizing-code-across-files.js. The exact filename may be changed freely. When a multi-file project exists, prefer its tsconfig.json and build scripts.

Task describes the domain shape; complete returns a new object instead of mutating the input. In a multi-file project, model.ts can export Task, task-service.ts can export complete, and main.ts can coordinate them.

The output shown above comes from the initialized values in this program. Replacing a type annotation alone does not transform a JavaScript value.

This separate mini-project demonstrates real imports, exports, or declarations across files. Create each file in one folder, then compile and run main.js. The example was checked separately from the single-file program.

model.ts

export type Task = {title:string;done:boolean};

service.ts

import type {Task} from "./model";export function finish(task:Task):Task{return {...task,done:true};}

main.ts

import {finish} from "./service";console.log(finish({title:"Learn",done:false}).done);

CommonJS setup: compile with npx tsc --strict --target es2022 --module commonjs main.ts and run node main.js. Compile from the same directory so relative modules are discovered. If this example contains helpers.js, keep that runtime file alongside the emitted main.js.

Verified output from the mini-project

true

A deeply nested directory structure adds complexity without necessarily improving module boundaries. Begin with meaningful responsibilities.

Check both the TypeScript diagnostic and the emitted JavaScript behavior. A program can compile correctly and still need runtime validation or error handling.

Split this example into model.ts, service.ts, and main.ts, importing only what each file needs.

Before running your change, write down the type you expect TypeScript to infer and the output you expect JavaScript to print. Then check both predictions.

Separate files by responsibility: domain definitions, reusable transformations, and application entry points.

Try the practice change and re-run the exact program to test your understanding.