Skip to Content
Find Which TypeScript Compiler Your Project Runs
Beginner
0 likes
Tutorials

Find Which TypeScript Compiler Your Project Runs

Trace a compiler version mismatch, confirm the resolved package path, and make a project-local check catch a deliberate type error.

A terminal can run one TypeScript compiler while your project uses another. Reinstalling Node does not establish which compiler checked the code. This guide traces the package, reproduces a version mismatch in separate practice folders, and makes the project check fail when its local compiler is missing.

1. Separate a missing command from a code error

Use a supported Node release with npm. These commands use PowerShell and were checked with Node 24.19.0, npm 12.2.0 and TypeScript 7.0.2. The version pins make this lab repeatable; keep your real project's agreed version. For an initial installation walkthrough, use the beginner course lesson.

node --version
npm --version
Get-Location
Get-Command tsc -All -ErrorAction SilentlyContinue

No bare tsc command is fine when the compiler is installed only in a project. A diagnostic such as TS2322 means a compiler ran and rejected code. Record the command and working directory before changing dependencies.

2. Prepare a project with a known compiler

Create an empty compiler-lab/project folder and work inside it. Save this package.json:

{
  "name": "compiler-selection-lab",
  "private": true,
  "devDependencies": {
    "typescript": "7.0.2"
  },
  "scripts": {
    "check": "node ./node_modules/typescript/bin/tsc --noEmit -p tsconfig.json"
  }
}

Save tsconfig.json:

{
  "compilerOptions": {
    "strict": true,
    "target": "ES2022",
    "module": "NodeNext"
  },
  "include": [
    "src/**/*.ts"
  ]
}

Create src/index.ts:

const title: string = "Compiler selected";
console.log(title);

Install from this folder, then inspect the installed dependency. The lockfile records the resolved dependency tree; keep it with a real project and use npm ci for repeat installations.

npm install
npm ls typescript --depth=0
node ./node_modules/typescript/bin/tsc --version
npm run check

The dependency and compiler report 7.0.2; the check exits successfully. This check script names the project compiler directly. If it is absent, Node fails instead of falling through to an unrelated command on PATH.

3. Print the resolved package path

Save compiler.cjs beside package.json, then run node compiler.cjs:

const path = require("node:path");
const manifest = require.resolve("typescript/package.json");
const pkg = require(manifest);
console.log("Node:", process.execPath);
console.log("Compiler package:", manifest);
console.log("Package version:", pkg.version);
console.log("Compiler entry:", path.join(path.dirname(manifest), pkg.bin.tsc));

Confirm that the manifest is inside this project's node_modules/typescript. If it resolves to an ancestor folder, you are using an ancestor dependency, even if the version looks right. In a workspace, check against the workspace's intended installation root. The printed entry path and the explicit check script let you connect the package version to the compiler you run.

4. Reproduce a mismatch without a global installation

This optional exercise puts a second, real compiler in the sibling tooling folder. It changes PATH only inside a try/finally block in this PowerShell session. The project dependency remains 7.0.2.

New-Item -ItemType Directory -Force ../tooling | Out-Null
npm install --prefix ../tooling --save-dev --save-exact typescript@5.9.3
if ($LASTEXITCODE -ne 0) { throw 'Tooling install failed.' }
$savedCompilerPath = $env:Path
try {
    $toolBin = (Resolve-Path ../tooling/node_modules/.bin).Path
    $env:Path = $toolBin + [IO.Path]::PathSeparator + $savedCompilerPath
    Get-Command tsc -All
    tsc --version
    npx --no -- tsc --version
    node compiler.cjs
    npm run check
} finally {
    $env:Path = $savedCompilerPath
}

Expected: bare tsc reports 5.9.3, while the project package and npx report 7.0.2. The -- ends npx option parsing so --version reaches the compiler. --no declines a missing-package install prompt; it does not itself prove the executable is project-local. Always pair that command with the resolved package path. If PowerShell blocks a command shim under your policy, use the corresponding .cmd command rather than weakening the policy.

5. Prove that the selected check reads your source

Temporarily replace the first source line with const title: string = 42;. Run npm run check: it must exit nonzero and show TS2322. Restore the string and run again. A version number alone cannot prove that your intended files were included in the check.

Observed resultNext check
Bare tsc missing; explicit local check passesKeep using the project command. No global compiler is required.
Two commands report different versionsCompare PATH lookup, working directory and resolved package path.
Local package cannot be foundRestore dependencies from the intended project root; use npm ci when a valid lockfile exists.
Version matches but the deliberate error passesInspect the check script and tsconfig include/exclude paths.

6. Keep the useful evidence

For a bug report, include Node/npm versions, working directory, compiler package path/version, the exact check command and its diagnostic. The editor may use its own compiler; select the workspace TypeScript version there separately. Removing the optional tooling folder later does not uninstall anything globally.

References: npm exec and executable resolution and TypeScript configuration.

About

Trace a compiler version mismatch, confirm the resolved package path, and make a project-local check catch a deliberate type error.

Responsible
Jay P
Last Update
10/13/2026
Reading Time
5 min
Was this helpful?
​ 0 ​ 0

Comments (0)

Sign in to comment

No comments yet.