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

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.

“npm install typescript@latest ts-node@latest”

Didn’t fix it for me.

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

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…

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

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

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.

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.

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

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.

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

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.

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.

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)

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!

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

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.

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

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.

you need to update ts node globally

npm install -g ts-node@latest

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"
    ],
    // ...
}

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.

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.

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