Closed vonlyinno closed 2 years ago
As the error message says, not a TS bug. https://github.com/microsoft/TypeScript/issues/47921
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?
You can install the old versions in this site: https://www.npmjs.com/package/typescript.
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.
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.
"npm install typescript@latest ts-node@latest"
Didn't fix it 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.
"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?
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,
Anyone using Caret Ranges or other vague versioning is going to eat it for this. 100s of man hours right there..
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.
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 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.
@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
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.
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.
@mendsalbert why are you so sure that everyone expecting this problem has ts-node-dev
module?
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.
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.
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.
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)
This was fixed for me when I manually installed ts-loader version 9.3.1 instead of whatever webpack etc was installing itself
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.
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?
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"
],
// ...
}
@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 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
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 had to downgrade typescript from
4.7.4
to4.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.
you need to update ts node globally
npm install -g ts-node@latest
I had to downgrade typescript from
4.7.4
to4.5.5
and it started working. No changes to ts-node (10.9.1
installed)
Thank you it worked
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 typenpm i ts-loader@v9.2.7 -D
thanks mate!
when I update npm package to v4.7.2, npm run build( script: vue-cli-service build ) got error:
It went well if I use v4.6.x.