Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8.0.3 breaks project with: Unable to require .d.ts file #797

Closed
hakan0xFF opened this issue Mar 7, 2019 · 36 comments · Fixed by #970
Closed

8.0.3 breaks project with: Unable to require .d.ts file #797

hakan0xFF opened this issue Mar 7, 2019 · 36 comments · Fixed by #970

Comments

@hakan0xFF
Copy link

hakan0xFF commented Mar 7, 2019

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.

@izatop
Copy link

izatop commented Mar 10, 2019

I spent some time after upgrade dependencies to find out who broke my project. I installed previous version of the package and it solved issue.

@hakan0xFF
Copy link
Author

It seems that this commit broke my project.

@murbanowicz
Copy link

The same problem here.

@andyianriley
Copy link

same here

@whxaxes
Copy link

whxaxes commented Mar 19, 2019

@blakeembrey any progress for this ?

@blakeembrey
Copy link
Member

Does anyone want to provide a reproduction or test case?

@mfellner
Copy link

mfellner commented Mar 20, 2019

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!

@svi3c
Copy link

svi3c commented Mar 21, 2019

I can confirm that this happens to me with yarn workspaces, too. But not every import from another workspace package fails. For example I've got a package with only type declarations and an import of those does not crash.

@nolazybits
Copy link

nolazybits commented Mar 25, 2019

yup, same problem.
Also using yarn workspaces.
Also I have added

  "resolutions": {
        "ts-node": "8.0.2"
  },

to the package.json

so ts-node-dev for instance use the right version (and not the latest broken 8.0.3)

@alcuadrado
Copy link

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

@mikebm
Copy link

mikebm commented Apr 16, 2019

Still an issue in 8.1.0.

@jLouzado
Copy link

@gianmarcotoso
Copy link

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

@ChristianIvicevic
Copy link

@gianmarcotoso Thank you for your suggestion, this helped me to resolve the issue in a similar setup. Furthermore enabling --transpile-only would've solved this as well which was a dirty fix though.

@ChristianIvicevic
Copy link

@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.

@SOF3
Copy link

SOF3 commented May 22, 2019

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".

@hakan0xFF
Copy link
Author

hakan0xFF commented May 22, 2019

I can confirm that adding "preserveSymlinks": true to tsconfig.json solves my problem too.

So moving from version <=8.0.2 to >8.0.2 somehow seems to be a breaking change if you are using symlinks without "preserveSymlinks": true.

@zacaj
Copy link

zacaj commented May 23, 2019

Running into this as well. preserveSymlinks seems to fix it, but I don't understand why. This error message is not very helpful at finding the issue

@blakeembrey
Copy link
Member

It looks like the issue was introduced when trying to better conform to the TypeScript compiler API by adding realpath: c215693#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.

@hakan0xFF
Copy link
Author

Happy to remove this and add back in a new major release, can anyone confirm removing this single line resolves things?

Yes, removing the realpath line and "preserveSymlinks": true from tsconfig.json resolves this issue, at least for me. 👍

@connor4312
Copy link

I've also just run into this in a totally separate scenario: I had mocha set to require a file that installed the ts-node loader via .register(), and also had an old reference in my nyc config that required ts-node/register-- it seems that registering ts-node twice can cause this issue.

Definitely an edge case but maybe ts-node should emit a warning or error if it's registered twice. (I think a no-op would be less desirable, since someone might be trying to register it with different options and wondering why none of the options are having any effect.)

@blakeembrey
Copy link
Member

Closing with 9691206 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 #409 - would love to see a PR 😄

@TorstenStueber
Copy link

Turns out that this actually is a breaking change that causes problems when using pnpm – see #876.

@skjo0c
Copy link

skjo0c commented Sep 20, 2019

This error is shown if I put my files inside src folder but not if I put them outside src. Does anyone know how to deal with it? I have tried preserveSymlinks but no luck. ts-node version is 8.3.0

@matthew-dean
Copy link

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

@blakeembrey
Copy link
Member

@matthew-dean Can you create a reproduction?

@matthew-dean
Copy link

@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

@matthew-dean
Copy link

@blakeembrey So maybe in my case, the error was legitimate because some node module had a test .ts file which wasn't actually compilable. 🤷‍♂

kamontat pushed a commit to kamontat/nd that referenced this issue Oct 8, 2019
@stewartmcgown
Copy link

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.

@bvalosek
Copy link

For anybody else who finds this from googling, my (probably very narrow) edge case:

  • we have a lerna mono repo, with all TS files in a src directory per package
  • we also have an index.ts at the root of each package for package exports
  • our includes array in tsconfig was "./packages/*/src/**/*.ts"
  • this all worked fine until it didn't. tsc ran fine but running tests with ts-jest didnt. It was throwing the error mentioned in this issue after some changes to the local dep graph.

my solution was to add "./packages/*/index.ts" to the includes array in tsconfig, and it worked fine after that.

@IonelLupu
Copy link

@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"

@sidferreira
Copy link

I think this is related to "moduleResolution": "node" that is limited on types ( https://www.typescriptlang.org/docs/handbook/module-resolution.html#node ).

I have a project with TS and Babel and I added .d.ts to the 'module-resolver' and it fixed the issue.

I'm just trying to find out how to connect ts-node to it... if I run tsc it works all good. If I run tsc only targeting my CLI (that is run with ts-node) things goes sideways.

@Morriz
Copy link

Morriz commented Aug 3, 2020

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.

@rajitha1998
Copy link

I am also facing the same issue with "ts-node": "^8.10.2" @blakeembrey. I am using yarn workspaces and Lerna.

@hanatharesh2712
Copy link

hanatharesh2712 commented Mar 22, 2022

I have resolved this issue by mentioning the file path in root of tsconfig.ts file
I am using the "ts-node": "^8.10.2"

"files": [ "node_modules/package-name/index.ts" ]

@fresheneesz
Copy link

I'm seeing this bug with a very basic script: just console.log("test") just to see it working. When my tsconfig.json contained "isolatedModules": true and when I named the file test.d.ts I get the error TypeError: Unable to require file.... It seems removing the isolatedModules constraint solves this. But it doesn't seem like that option should have anything to do with it. My file had no imports at all. AFAICT, something is going wrong here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.