Initialize a TypeScript npm Project and Verify Strict Checking

A useful first TypeScript check is one you can make fail on purpose. Start with a typed parameter, check the project, then remove the annotation. If the second check reports an implicit any, you have evidence that the compiler is checking that file under your strict configuration—not just that TypeScript was installed.

Create the npm package and install TypeScript

From an empty project directory, create package.json and follow npm’s prompts. Then install the compiler and Node.js type definitions as development dependencies:

npm init
npm install --save-dev typescript @types/node

This starter uses TypeScript to check and compile source during development; @types/node supplies Node.js types for code that uses Node APIs. The example below does not need a Node-specific API, but keeping the definitions in the project makes the setup ready for one. The Node.js TypeScript setup example uses development dependencies for both packages.

Generate a configuration, then make its choices explicit

Run the project’s compiler to create a configuration file:

npx tsc --init

Replace the generated contents with this compact tsconfig.json:

{
  "compilerOptions": {
    "target": "es2020",
    "module": "commonjs",
    "outDir": "./dist",
    "strict": true
  },
  "include": ["src/**/*.ts"]
}

ES2020, CommonJS, and dist are choices for this small Node starter, not settings every project needs. The include pattern identifies the source files this example intends to check. Writing strict: true explicitly makes the intended checking level visible even if generated configuration changes. TypeScript’s strict documentation describes it as enabling the strict-mode family of checks; it also notes that a future TypeScript version may add checks under that flag and expose new errors after an upgrade.

Give the checker one typed file

Create src/index.ts:

function greet(name: string): string {
  return `Hello, ${name}`;
}

console.log(greet("team"));

Check the configured project from its root:

npx tsc --project tsconfig.json

With the file above, this check should pass. The command names the configuration rather than passing src/index.ts as an input argument. That distinction matters: the TypeScript CLI documentation says that supplying input files on the command line causes tsconfig.json files to be ignored. Here, --project directs the compiler to the configuration whose include and strict settings you want to test.

Make the strict check fail, then fix it

Temporarily remove only the parameter annotation. This is the deliberately invalid version of the function:

function greet(name): string {
  return `Hello, ${name}`;
}

console.log(greet("team"));

Run the same project check again:

npx tsc --project tsconfig.json

Expect an implicit-any error for name. The noImplicitAny check is enabled by strict, and an unannotated parameter with no inferred type is the case this probe is designed to expose. If it fails that way, the result supports a narrow conclusion: this included source file is being checked with that strict rule active. It does not prove that every future file is included or that values arriving at runtime are valid.

Restore name: string and run the command once more; the original example should pass again. Keep that final, typed version in the project. This check establishes a working starting configuration, not a test of the program’s runtime behavior. When data enters the application from an external source, its contents need a separate runtime check; a TypeScript annotation cannot inspect the value for you.