microsoft / TypeScript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
https://www.typescriptlang.org
Apache License 2.0
100.51k stars 12.43k forks source link

update to npm v4.7.2, got error: False expression: Non-string value passed to `ts.resolveTypeReferenceDirective` #49257

Closed vonlyinno closed 2 years ago

vonlyinno commented 2 years ago

when I update npm package to v4.7.2, npm run build( script: vue-cli-service build ) got error:

INTERNAL ERROR(undefined,undefined) Debug Failure. False expression: Non-string value passed to `ts.resolveTypeReferenceDirective`, likely by a wrapping package working with an outdated `resolveTypeReferenceDirectives` signature. This is probably not a problem in TS itself.
stack trace:
Error: Debug Failure. False expression: Non-string value passed to `ts.resolveTypeReferenceDirective`, likely by a wrapping package working with an outdated `resolveTypeReferenceDirectives` signature. This is probably not a problem in TS itself.

It went well if I use v4.6.x.

fatcerberus commented 2 years ago

As the error message says, not a TS bug. https://github.com/microsoft/TypeScript/issues/47921

Francosf7 commented 2 years ago

Hi, sorry if this has already been answered, but should we revert our TS version or Ts-node version to a specific v4.X.X version in our projects in order for this error to go away? Or how do we make it go away?

vmoreirav commented 2 years ago

You can install the old versions in this site: https://www.npmjs.com/package/typescript.

link89 commented 2 years ago

Have the same problem and npm install typescript@latest ts-node@latest fix my issue.

Update: The root cause in my case is old version of ts-node use legacy API of typescript that no longer support by typescript after specific version, so the command above fix my problem as new version of ts-node fix the issue. For the other cases that this fix won't work, you should find out the exact package that throw the error, and try to either upgrade it or downgrade typescript to a fixed version as a workaround.

fatcerberus commented 2 years ago

Why all the downvotes on my comment? The issue is with ts-node, not TypeScript. That’s why the error message is worded the way it is, as it was a known breaking change.

mvaljento commented 2 years ago

"npm install typescript@latest ts-node@latest"

Didn't fix it for me.

RyanCavanaugh commented 2 years ago

Please see (and don't thumb-down!) fatcerberus's comment above. The message explicitly states that the API consumer is out-of-date.

hamzou247 commented 2 years ago

"npm install typescript@latest ts-node@latest"

Didn't fix it for me.

Same having the error and switching versions didn't make it. Should we ask in other repo?

aentwist commented 2 years ago

I do not have ts-node in my project. So pinning a ts-node version is irrelevant?

$ yarn why ts-node
yarn why v1.22.15
[1/4] Why do we have the module "ts-node"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
error We couldn't find a match!
Done in 0.66s.

There was a breaking change in a feature release of TypeScript? The error message describes changing the signature of a method. When pinning the typescript version down from 4.7.2 to 4.6.4 fixes it without doing anything else, how can you say

not a problem in TS itself

Do you expect package authors to keep up if you completely disregard SemVer?

Summary
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,

https://semver.org

Anyone using Caret Ranges or other vague versioning is going to eat it for this. 100s of man hours right there..

JavierPAYTEF commented 2 years ago

This new assert made me loose like 4 hours trying to figure out the issue, just downgrading typescript to version 4.4.4 fixed it for me.

It's a problem that the message doesn't explicitly says which dependency is causing the problem. In my particular case it was firebase and @types/qr-code. I would have never guessed it in a million years, I had to start writing console.logs everywhere to find it.

I don't really understand why such an assert was added in the first place, if it's so common for dependencies to send an object instead of a string, why don't it simply accepts the object and processes it accordingly.

If both of those random dependencies broke I can't imagine the amount of dependencies that will need to be fixed for this to work again, people will end up downgrading typescript version instead.

JavierPAYTEF commented 2 years ago

Why all the downvotes on my comment? The issue is with ts-node, not TypeScript. That’s why the error message is worded the way it is, as it was a known breaking change.

@fatcerberus I think people were annoyed you seem to be repeating what the error says but not giving a solution. Also this doesn't just happen with ts-node, I don't even have that as dependency in my project, and it was working fine until I updated the typescript version

fatcerberus commented 2 years ago

I think people were annoyed you seem to be repeating what the error says but not giving a solution.

Yes, because it’s not something that the TypeScript team can fix. The problem is that something in your toolchain is calling an API with the wrong parameter, and the solution will depend on exactly which tool that is. We literally can’t provide any more information than the error message already does.

It's a problem that the message doesn't explicitly says which dependency is causing the problem.

How do you propose TS is supposed to know that? It just knows that someone called a function with a bad value.

JavierPAYTEF commented 2 years ago

@fatcerberus I was just answering your question. But on a side note, there is actually solution/workaround, downgrading typescript to a version before 4.7. Version 4.7 is the one that introduced the assert that causes the problem. I'm not aware exactly what it was trying to solve by doing that, since we are not using ts-node, and it's actually a problem for us, not a solution.

About your second question, if you look at the function that throws the issue you will see the parameters are right there, just printing them in the exception would be enough, at least to get a clue of what is happening: image

containingFile is the most important one, since it tells you the file

fatcerberus commented 2 years ago

btw the assert was added to catch the error early (and mention that it’s not a TS issue) because originally it was failing later on with a completely inscrutable error message.

mendsalbert commented 2 years ago

First of all Open Your package.json file. -Under dependencies, you can see there is ts-node-dev dependence present. -Just Update its version to the very latest one 2.0.0-0. -Then run npm install to get all packages. And Now, Your error may be solved.

justice47 commented 2 years ago

@mendsalbert why are you so sure that everyone expecting this problem has ts-node-dev module?

DaveStein commented 2 years ago

I just upgraded to latest typescript at 4.7.4 and am one of the users with no ts-node, yet I am experiencing this error. As other people say, typescript should follow semver. The difference between 4.6.4 and 4.7.4 should not be breaking.

Lori-Becker commented 2 years ago

For the other cases that this fix won't work, you should find out the exact package that throw the error, and try to either upgrade it or downgrade typescript to a fixed version as a workaround.

How do you determine which package throws this ts.resolveTypeReferenceDirective error? Nothing in my terminal tells me what dependency is causing this error. I've been waiting for a fix for this for 2 months. I cannot use any TS version except 4.7.* due to some dependency requirements so downgrading isn't an option for me.

DaveStein commented 2 years ago

I should note changing the line mentioned from @JavierPAYTEF / stacktrace to this, will tell you what's wrong. He's right about that.

ts.Debug.assert(typeof typeReferenceDirectiveName === "string", containingFile + "Non-string value passed to `ts.resolveTypeReferenceDirective`, likely by a wrapping package working with an outdated `resolveTypeReferenceDirectives` signature. This is probably not a problem in TS itself.");`

You just need to know containingFile and then you can look in your lock to figure why you have it. I am currently solving one issue at a time. Lots of my @types/XYZ libs are broken, that are dependencies of my dependencies.

DaveStein commented 2 years ago

I ended up going with the downgrade route because I had too many dependencies that had dependencies that flagged this exception. This exception should only be in 5+, according to semver rules. Breaking on a minor release isn't good for anyone. At the very least the exception should give the source of containingFile and be a warning until a real breaking version.

ojasd commented 2 years ago

I had to downgrade typescript from 4.7.4 to 4.5.5 and it started working. No changes to ts-node (10.9.1 installed)

dariusj18 commented 2 years ago

This was fixed for me when I manually installed ts-loader version 9.3.1 instead of whatever webpack etc was installing itself

andrewheumann commented 2 years ago

this issue started happening for me when I installed jszip, but it seems ts-loader was the culprit for me too. Had to update to ^8 instead of latest/9 because 9 is incompatible w/ webpack 4.

Hobart2967 commented 2 years ago

Having everything updates, typescript, ts-loader, ts-node to the latest version. ts-node-dev is not in my package list, not even after installing all sub-packages.

Issue still persists. What to do now?

Hobart2967 commented 2 years ago

Tip: In my case, it was a vue2 project with webpack. There, I accidently removed the property "types" from the tsconfig. Re-Adding webpack-env to types solved the problem for me:


{
  "compilerOptions": {
    // ...
    "types": [
      "webpack-env"
    ],
    // ...
}
JavierPAYTEF commented 2 years ago

@Hobart2967 A lot of people made it seem like this is a ts-node issue, it's not. I had 6 dependencies with problems and none of them were ts-node, a lot of @types/* dependencies broke.

This is basically a breaking change for a lot of dependencies, and I don't see them updating any time soon, specially the types definitions.

If you have this issue, the only option for now, is to downgrade typescript to a 4.6 version: npm install typescript@^4.6

If you want more details on how to find which module is the one with problems, check my comment from Jun 10

Hobart2967 commented 2 years ago

@Hobart2967 A lot of people made it seem like this is a ts-node issue, it's not. I had 6 dependencies with problems and none of them were ts-node, a lot of @types/* dependencies broke.

This is basically a breaking change for a lot of dependencies, and I don't see them updating any time soon, specially the types definitions.

If you have this issue, the only option for now, is to downgrade typescript to a 4.6 version: npm install typescript@^4.6

If you want more details on how to find which module is the one with problems, check my comment from Jun 10

Sorry but I am using Typescript 4.5 over here, so there's nothing to downgrade :D

EricWong1994 commented 2 years ago

if you are using webpack4,you can try npm i ts-loader@8.4.0 -D ,this version ts-loader has fixed the problem above. if webpack 5,you need type npm i ts-loader@v9.2.7 -D

sashiksu commented 2 years ago

I had to downgrade typescript from 4.7.4 to 4.5.5 and it started working. No changes to ts-node (10.9.1 installed)

In my case, I have to set allowSyntheticDefaultImports to true.

izorwebid commented 1 year ago

you need to update ts node globally

npm install -g ts-node@latest

benmotyka commented 1 year ago

I had to downgrade typescript from 4.7.4 to 4.5.5 and it started working. No changes to ts-node (10.9.1 installed)

Thank you it worked

gabrielfremd commented 1 year ago

if you are using webpack4,you can try npm i ts-loader@8.4.0 -D ,this version ts-loader has fixed the problem above. if webpack 5,you need type npm i ts-loader@v9.2.7 -D

thanks mate!