Fix tsc is not recognized: run the local compiler

TL;DR#

A local TypeScript installation does not put tsc on the Windows shell's PATH. Confirm that the project has the typescript dependency, then run the compiler through an npm script instead of typing a bare tsc command. For a custom VS Code task, use an npm task or run Node with the project compiler's explicit path. Changing compiler settings cannot fix a command that Windows has not started.

The original Stack Overflow report installed TypeScript as a development dependency deliberately, then encountered this message when building in VS Code:

tsc is not a recognized as an internal or external command...

That report used an older task format, but its central distinction still matters: the compiler can be present in the project while a task's bare command remains unavailable to Windows. The accepted answer gave Node the local compiler's path. The same principle works with current npm scripts, which provide local commands to the process running the script.

Why it happens#

There are separate locations to inspect. The typescript package belongs in the project's dependencies; npm creates its executable launcher under node_modules/.bin. Microsoft documents that Command Prompt searches the current directory and the directories in PATH. It does not recursively search every dependency folder just because the current directory contains a package.json.

The npm folder documentation describes local executable links under node_modules/.bin. The npm run documentation explains the other half: npm adds that directory to the PATH supplied to package scripts. Thus the same text, tsc -p tsconfig.json, can fail when entered directly and succeed inside an npm build script.

VS Code adds another distinction. Its TypeScript documentation separates the editor's language service from the installed compiler. Syntax highlighting, completion and type diagnostics do not demonstrate that a shell can find the project's command. Likewise, choosing the workspace TypeScript version for the editor does not rewrite a custom shell task's command.

Fix#

These commands use Windows Command Prompt, opened in the folder containing the relevant package.json. For an existing application, use its package folder rather than an unrelated parent directory. In PowerShell, use where.exe for the Windows lookup command and npm.cmd or npx.cmd if PowerShell's script policy blocks their script launchers.

1. Establish whether the compiler is actually installed#

Check the runtime, package manager and local dependency before changing anything:

node --version
npm --version
npm ls typescript --depth=0

A listed TypeScript dependency is evidence of an installation; an entry in package.json alone is only a request for one. Inspect the launcher and test it directly:

dir node_modules\.bin\tsc.cmd
node node_modules/typescript/bin/tsc --version

If that direct command prints a compiler version while the bare command fails, the compiler is available and command lookup is the immediate problem. Keep the installed version while repairing the invocation. Reinstalling it globally at this point changes the compiler selection as well as command availability, making the result harder to assess.

If the local package is missing in a new project, install it with the project installation command documented by TypeScript:

npm install --save-dev typescript

For an established repository, follow its dependency installation instructions and lockfile instead of treating a new compiler version as the fix. This article's reproduced case already had TypeScript installed. If the failure occurs inside a container and the package or executable link is absent there, follow the Docker build diagnosis for missing tsc, which examines skipped development dependencies and missing binary links in the build stage.

2. Run the compiler in an npm script#

Add a build entry to the scripts object in package.json. This is a complete minimal example; merge the entry into your application's existing object rather than replacing its other scripts or dependency declarations:

{
  "private": true,
  "scripts": {
    "build": "tsc -p tsconfig.json"
  }
}

Then invoke the script:

npm run build

This changes how the compiler is launched. npm supplies the local executable directory, and the compiler reads the specified project configuration. The TypeScript command reference documents project compilation. Passing individual input files is a different invocation: current TypeScript reports TS5112 when the working directory also contains a tsconfig.json. The TypeScript release note explaining this change documents the error, which was also reproduced with the tested compiler. Keep the project invocation for builds; use the version command to test command availability.

For an occasional interactive invocation, first confirm the local dependency, then run:

npx tsc --version

Do not use a successful npx command as your only proof that the project installed the compiler. npm exec documents that requested packages missing locally can be fetched into npm's cache. For a diagnostic that declines an installation request, use:

npm exec --no -- tsc --version

The separator passes the following compiler arguments to the executed command. Keeping the dependency check before either invocation also avoids guessing a package from the name of a missing command.

3. Make the VS Code build task use the same route#

If the terminal script succeeds but your custom task still reports the Windows command error, inspect .vscode/tasks.json. A shell task that still says "command": "tsc" is still requesting ordinary shell lookup. Configure an npm task to run the working package script:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Compile project TypeScript",
      "type": "npm",
      "script": "build",
      "problemMatcher": ["$tsc"],
      "group": {
        "kind": "build",
        "isDefault": true
      }
    }
  ]
}

The VS Code task documentation describes npm tasks and problem matchers. Select this task through Run Build Task. Its npm route keeps the editor build and terminal build attached to the same package script.

If a custom process task is required, this alternative follows the original answer's explicit-path approach using the current task format:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Compile with the local compiler path",
      "type": "process",
      "command": "node",
      "args": [
        "${workspaceFolder}/node_modules/typescript/bin/tsc",
        "-p",
        "${workspaceFolder}/tsconfig.json"
      ],
      "problemMatcher": ["$tsc"]
    }
  ]
}

Here Windows finds Node, then Node receives the compiler file as an argument. Paths with spaces remain individual arguments in the process task. Use one task approach for the build you are fixing; there is no benefit in leaving an obsolete bare-command task as the selected default.

Verify the fix#

This failure was reproduced natively on Windows on 9 October 2026 with Node.js 26.7.0, npm 11.19.0 and TypeScript 7.0.2. The test installed the package locally, confirmed that its launcher existed, and used a small project with a configured source directory and output directory. The operating system's error messages were French; the observed command lookup output began:

'tsc' n'est pas reconnu en tant que commande interne

Changing only the invocation from the bare project command to the already-defined npm build script produced this output and a successful exit:

> aotd-windows-local-tsc@1.0.0 build
> tsc -p tsconfig.json

Running the generated JavaScript then printed:

The project compiler ran

The direct compiler path and npx also reported the same installed compiler version:

Version 7.0.2

No package installation, source change, tsconfig change or global PATH change occurred between the failing command and successful npm build. A fresh Command Prompt process still failed on bare tsc afterwards. That confirms the fix made the local compiler available to the build, without making it a machine-wide command. The native test covered the underlying commands; the VS Code task configurations above follow the documented task formats.

For your own project, run its build script, inspect its current diagnostics and check the expected output. Do not make where.exe tsc returning a global path your success criterion. A project can build correctly through npm while that global lookup still finds nothing.

When the compiler starts, the diagnosis changes#

The original question's update reported many compiler errors after fixing the task and then changed an exclusion setting. Those are successive failures. An exclusion setting is read by a running compiler; it cannot help Windows locate that compiler. In the reproduction, adding node_modules to the exclusion list left the bare command failure unchanged. Restore unnecessary configuration experiments before investigating the newly visible diagnostics.

If compilation now reports Cannot find name 'console', continue with the TypeScript console declaration diagnosis. That page checks the loaded library and Node type declarations. It addresses a compiler diagnostic reached after command execution succeeds.

If the package build succeeds while the editor still reports the JSX flag error, follow the workspace TypeScript checks for the JSX error. Choosing the editor's TypeScript version belongs to that disagreement, while the npm script or explicit compiler path handles the Windows command lookup failure. Keep the working build command as the reference point and investigate the actual next diagnostic it produces.

Further reading: Fix npm WARN package.json: No repository field.