Publié · en amélioration
Guide TypeScript · 4/6
Ce chapitre n'est disponible qu'en anglais pour le moment.
As a program grows you split it across files and start pulling in packages written by other people. TypeScript uses the standard JavaScript module system, ES modules, and adds a way to share type information across those boundaries. This chapter covers import and export, npm packages and package.json, @types declaration packages, the module-related tsconfig options, and how to build.
Each file is its own module. Mark the values and types other files may use with export, and bring them in with import.
// src/math.ts
export const PI = 3.14159;
export function circleArea(radius: number): number {
return PI * radius * radius;
}
export interface Range {
min: number;
max: number;
}
export default function clamp(value: number, range: Range): number {
return Math.min(range.max, Math.max(range.min, value));
}// src/index.ts
import clamp, { circleArea, PI } from "./math.js";
import type { Range } from "./math.js";
import * as math from "./math.js";
const range: Range = { min: 0, max: 10 };
console.log(clamp(15, range)); // 10
console.log(circleArea(2), PI);
console.log(math.circleArea(1));A few details are worth calling out:
import type declares that only types are needed. It is erased completely from the output, so it never creates a runtime dependency.module set to nodenext, relative imports need a file extension, and you write the extension of the compiled file, .js, even though the source is .ts. The compiler maps it back to the .ts file for you.package.json records your project's name, dependencies, and scripts. Packages needed at runtime belong in dependencies; tools used only during development belong in devDependencies.
npm install zod # runtime dependency
npm install --save-dev vitest # development tool
npm install # install everything listed in package.json
npm outdated # see which packages have newer versions{
"name": "hello-ts",
"type": "module",
"main": "dist/index.js",
"scripts": {
"build": "tsc",
"test": "vitest"
}
}"type": "module" tells Node.js to treat the package's .js files as ES modules. Running npm install adds entries to or for you, usually as caret ranges (a version prefixed with ) that accept compatible updates. The generated pins the exact versions that were installed, so commit it alongside your code.
dependenciesdevDependencies^package-lock.jsonTypeScript learns the shape of a JavaScript library from .d.ts declaration files. Many packages now ship their own declarations, so their types appear as soon as you install them. For packages that do not, the community-maintained DefinitelyTyped project publishes separate @types/package-name packages.
npm install express
npm install --save-dev @types/express @types/node@types/node provides types for built-in modules such as fs, path, and process. Importing built-ins with the node: prefix makes it obvious where they come from:
import { readFile } from "node:fs/promises";
import path from "node:path";
const file = path.join(process.cwd(), "package.json");
const pkg = JSON.parse(await readFile(file, "utf8")) as { name: string };
console.log(pkg.name);Top-level await only works in ES modules, so this requires an ES module output setting such as nodenext. The as keyword is a type assertion: it tells the compiler what to assume but performs no runtime check. For external input, a validation library is the safer route.
| Option | Purpose |
|---|---|
target | Output syntax level; match what your runtime supports |
module | Use nodenext when Node.js runs the output directly |
moduleResolution | Use bundler together with module: esnext behind a bundler |
lib | Which built-in API types are available, such as the DOM |
declaration | Emit .d.ts files for library consumers |
verbatimModuleSyntax | Requires import type for type-only imports |
esModuleInterop | Smooths default imports from CommonJS packages |
As a rule of thumb, Node.js back ends use module: nodenext, while front ends built with a bundler such as Vite use module: esnext with moduleResolution: bundler.
tsc both type-checks and emits JavaScript. If you publish a library, turn on declaration so consumers get .d.ts files, and describe the entry points in package.json:
{
"name": "my-lib",
"type": "module",
"exports": {
".": {
"types": "./dist/index.d.ts",
"default": "./dist/index.js"
}
},
"files": ["dist"]
}Applications often hand the transpiling job to a bundler such as esbuild or Vite, which is much faster than tsc. Most of these tools strip types without checking them, so keep tsc --noEmit in your CI pipeline.
export, consume with import, and use import type for type-only imports.nodenext, relative imports carry a .js extension.dependencies, tooling in devDependencies, and the lock file gets committed.@types/package-name package.tsc --noEmit separately.
0 commentaire
Se connecter · Connectez-vous pour laisser un commentaire.
Soyez le premier à commenter.