How to fix Cannot use module imports with triple-slash directives in TypeScript

TypeScriptBEGINNERMEDIUMUpdated Dec 11, 2025· 83 views

TypeScript raises this diagnostic when a file that already declares itself as a module still tries to pull in another module using `/// <reference ... />`. Triple-slash directives belong to legacy script ordering and are incompatible with ES module imports, so the compiler refuses to emit the file.

Quick fix

Fixes Cannot use module imports with triple-slash directives

/// <reference path="./counter.ts" />
import { counter } from "./counter";
  1. Drop the triple-slash reference and rely on the module import
  2. Keep triple-slash directives inside pure declaration/script files
  3. Let tsc or your bundler manage ordering
typescript — error
/// <reference path="./counter.ts" />
import { counter } from "./counter";
Cannot use module imports with triple-slash directives

What this error means

Triple-slash directives operate on the assumption that TypeScript is compiling a batch of script files in a specific order. Once you add an `import` or `export` statement anywhere in the file, the compiler treats that file as a module and switches to module resolution. At that point, the module system already tracks dependencies, so a triple-slash directive that points at another module is redundant and violates the compiler's assumptions. Instead of blending the two systems, TypeScript stops and shows "Cannot use module imports with triple-slash directives" to force you to rely entirely on module imports (or keep the triple slashes inside a pure script).

Typical symptoms

  • Compilation halts with 'Cannot use module imports with triple-slash directives' pointing at a `/// <reference` line.
  • The error reports even though the referenced file is already imported via ES modules or CommonJS.
  • The file that triggers the error contains `import`/`export` statements and at least one triple-slash directive that looks like a dependency reference.
  • Switching the same file to plain script mode (remove imports/exports) makes the error disappear, confirming the mix of systems is the issue.
  • Builds that walk through triple-slash directives (`--outFile`, `tsc --build`) stop before creating output, even though the dependent modules compile fine in isolation.

Common causes

  1. A module file still contains `/// <reference path="./Other.ts" />` even though it now imports from `Other`.
  2. Legacy bundles that used triple-slash ordering have been converted to modules, but the directives were left in place.
  3. Ambient declaration files acquired exports or imports, so including them via triple-slash inside a module now triggers the conflict.
  4. The tsconfig `files` list mixes module entry points with files that rely on triple-slash references, so the compiler hits the directive after recognizing the file as a module.
  5. A hybrid build tries to keep the reference graph from TypeScript's `///` comments while also loading dependencies with modern imports, producing an ambiguous dependency graph.

How to fix "Cannot use module imports with triple-slash directives"

1Drop the triple-slash reference and rely on the module import

Modules already declare their dependencies with import statements, so you can drop the legacy directive. Replace this pattern:

ts
/// <reference path="./counter.ts" />
import { counter } from "./counter";

with just the import:

ts
import { counter } from "./counter";

Now rerun npx tsc (or your build script) to confirm the compiler no longer sees a triple-slash directive inside a module, and the diagnostic vanishes.

2Keep triple-slash directives inside pure declaration/script files

If you still need triple-slash directives for global declarations (for example, a legacy ./globals.d.ts that pulls in ambient helpers), move them into a file that never imports or exports. Example:

ts
// globals.d.ts
/// <reference path="./legacy-d.ts" />
declare global {
  interface Window { debug: boolean; }
}

Include globals.d.ts via the tsconfig.json files or include array instead of referencing it from a module. Modules can import the types declared there, but they should not contain their own triple-slash directives.

3Let tsc or your bundler manage ordering

Modern builds rely on module resolution to determine dependency order. Run:

bash
npx tsc --traceResolution | rg "reference path" -n

If the trace no longer prints your module file, the compiler reads only the import graph. For outFile bundles, use the files array or project references to maintain order, and avoid adding triple-slash comments inside modules. Once the offending directive is removed, the error disappears and the build completes normally.

Frequently asked questions

What does "Cannot use module imports with triple-slash directives" mean?
Triple-slash directives operate on the assumption that TypeScript is compiling a batch of script files in a specific order. Once you add an import or export statement anywhere in the file, the compiler treats that file as a module and switches to module resolution. At that point, the module system already tracks dependencies, so a triple-slash directive that points at another module is redundant and violates the compiler's assumptions.
How do I fix "Cannot use module imports with triple-slash directives"?
TypeScript raises this diagnostic when a file that already declares itself as a module still tries to pull in another module using /// <reference ... />. Triple-slash directives belong to legacy script ordering and are incompatible with ES module imports, so the compiler refuses to emit the file.
What causes "Cannot use module imports with triple-slash directives"?
A module file still contains /// <reference path="./Other.ts" /> even though it now imports from Other. Legacy bundles that used triple-slash ordering have been converted to modules, but the directives were left in place. Ambient declaration files acquired exports or imports, so including them via triple-slash inside a module now triggers the conflict.
Is the "Cannot use module imports with triple-slash directives" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading