ts-node: 8.0.3 breaks project with: Unable to require `.d.ts` file

Hey, today I upgraded the ts-node package to the newest version 8.0.3 and it now throws an exception:

TypeError: Unable to require `.d.ts` file.
This is usually the result of a faulty configuration or import. Make sure there is a `.js`, `.json` or another executable extension and loader (attached before `ts-node`) available alongside `graphql.schema.ts`.
    at getOutput (backend/server/node_modules/ts-node/src/index.ts:343:15)
    at Object.compile (backend/server/node_modules/ts-node/src/index.ts:368:11)
    at Module.m._compile (backend/server/node_modules/ts-node/src/index.ts:414:43)
    at Module._extensions..js (internal/modules/cjs/loader.js:745:10)
    at Object.require.extensions.(anonymous function) [as .ts] (backend/server/node_modules/ts-node/src/index.ts:417:12)
    at Module.load (internal/modules/cjs/loader.js:626:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:566:12)
    at Function.Module._load (internal/modules/cjs/loader.js:558:3)
    at Module.require (internal/modules/cjs/loader.js:663:17)
    at require (internal/modules/cjs/helpers.js:20:18)

The version 8.0.2 works. I had no time to find the exact cause.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 51
  • Comments: 36 (4 by maintainers)

Commits related to this issue

Most upvoted comments

I solved by adding "preserveSymlinks": true to my tsconfig.json file. This was happening within a lerna project, so YMMV.

Still an issue in 8.1.0.

I am running into this issue with ts-node 8.0.3, yarn workspaces and TypeScript project references. I was able to reproduce the issue in this minimal example: https://github.com/mfellner/ts-node-issue-797

8.0.2 does not exhibit the problem. Hope that helps!

This is still an issue as of 8.4.1, and the preserveSymlinks doesn’t seem to fix it.

@bvalosek In my case, it didn’t solve the error. (I am not using lerna) 😥

This is still an issue on "ts-node": "8.10.1"

I think it may be related to using --files and having tsconfig.json’s "include" field matching .d.ts files.

Another edge case for people who get here via 'cannot require .d.ts file:

I had a folder in my src called graphql where I was storing queries, mutations etc, but it required the module graphql. Since I had baseUrl set to src, ts-node was resolving the attempted reference to the npm module graphql to the folder that was asking for it.

Turns out that this actually is a breaking change that causes problems when using pnpm – see https://github.com/TypeStrong/ts-node/issues/876.

Closing with https://github.com/TypeStrong/ts-node/commit/9691206def28405d4e53c5a7753f96d15be46e79 for now, does anyone know if this behavior is desirable (aside from being a breaking change right now). Released in 8.1.1. For double registering, see https://github.com/TypeStrong/ts-node/issues/409 - would love to see a PR 😄

I am able to reproduce this issue reliably, and preserveSymlinks indeed solves the problem.

Given these files:

$ cat /test/foo/package.json
{
  "name": "foo"
}

$ cat /test/foo/foo.ts
export function foo(){ console.info("Hello world) }

$ cat /test/bar/package.json
{
  "name": "bar"
}

$ cat /test/bar/bar.ts
import {foo} from "foo/foo"
foo()
  1. cd /test/foo && npm link
  2. cd /test/bar && npm link foo
  3. cd /test/bar && ts-node bar

One can reliably get this error:

/usr/lib/node_modules/ts-node/src/index.ts:368
        throw new TypeError(
              ^
TypeError: Unable to require `.d.ts` file.
This is usually the result of a faulty configuration or import. Make sure there is a `.js`, `.json` or another executable extension and loader (attached before `ts-node`) available alongside `foo.ts`.
    at getOutput (/usr/lib/node_modules/ts-node/src/index.ts:368:15)
    at Object.compile (/usr/lib/node_modules/ts-node/src/index.ts:393:11)
    at Module.m._compile (/usr/lib/node_modules/ts-node/src/index.ts:439:43)
    at Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Object.require.extensions.(anonymous function) [as .ts] (/usr/lib/node_modules/ts-node/src/index.ts:442:12)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)

By (only) adding this file:

$ cat /test/bar/tsconfig.json
{
  "compilerOptions": {
    "preserveSymlinks": true
  }
}

ts-node bar would successfully output “Hello world”.

@gianmarcotoso Minor update: preserveSymlinks is causing issue in my case. In a library inside the monorepo that is not transpiled to JS and included as-is changes are not propagated to the main application source files unless the TS server is restarted which is apparently by design as can be seen here: microsoft/TypeScript/issues/30447

Currently I am experimenting with only creating a typings file or reverting to --transpile-only in the meantime.

As @IonelLupu said this is still an issue, even with 8.10.2. Renaming the conflicting .d.ts file to not use .ts resolves the problem, but only after a restart of the typescript server. We don’t use babel and tsc works fine.

@blakeembrey In my case, I think it was actually because my mocha test path was set to **/__tests__/*.ts, which I think was then globbing node_modules, and some .ts file in there was failing. I fixed it by making sure I was globbing src/**/__tests__/*.ts

It looks like the issue was introduced when trying to better conform to the TypeScript compiler API by adding realpath: https://github.com/TypeStrong/ts-node/commit/c21569372e0d8ba79c059771929d18568a910c77#diff-f41e9d04a45c83f3b6f6e630f10117feR296. Happy to remove this and add back in a new major release, can anyone confirm removing this single line resolves things?

I’ll also look into improving this error when I can, it hadn’t come up in the past that the TypeScript compiler would give empty files back except when compiling .d.ts files - so the error was unfortunately a red herring trying to help some people who do require a .d.ts file.