Repository navigation
Type error only through ts-loader #637
Description
I posted this question: https://stackoverflow.com/questions/46289856/why-does-a-heterogeneous-result-of-promise-all-cause-a-ts-error
Seems like this error only occurs through ts-loader, and is not erroneous through tsc on its own.
Our project Typescript version is 2.5.2. This error is produced in 2.4.2. Does ts-loader gather its type information from a vendored typescript?
Activity
johnnyreilly commentedon Sep 19, 2017
No. Do you have a different version of TypeScript in your package.json?
quicksnap commentedon Sep 19, 2017
@johnnyreilly I forked the vanilla example and replicated the issue. Steps are in the readme. Should be pretty fast to replicate.
https://github.com/quicksnap/loader-issue
johnnyreilly commentedon Sep 19, 2017
Hum. That's weird. I'll try and take a look when I get a moment. Not sure when that will be which doesn't help you I know. I'm wondering if it's going to be something to do with typescript 2.4 being installed globally for you or something. Not sure
quicksnap commentedon Sep 19, 2017
Could you replicate it? My system doesn't have typescript 2.4 on it anywhere that I can tell. When the yarn.lock also doesn't contain any ts 2.4 resolutions.
I'm at a loss as to what's causing this.
quicksnap commentedon Sep 19, 2017
We have a workaround via type hinting in our actual code, so this isn't causing a terrible amount of trouble. But, if it is due to some kind of typescript version mismatch, that could cause other strange behavior down the line.
Thanks for taking a look whenever you get time. I'll try and dig in further when I get a chance as well.
johnnyreilly commentedon Sep 20, 2017
Yup I can repro this. I have literally no idea what is causing it. If you can look into it I'll give you all the help I can. I'm afraid I can't look into this myself at present
quicksnap commentedon Sep 20, 2017
Totally understand. It's really baffling..
elldritch commentedon Dec 9, 2017
I'm seeing weirdness too, where
ts-loader's type-checking fails buttsc's type-checking succeeds. For me, the definition ofRequestInitinlib.es6.d.ts:6569is different between the two.johnnyreilly commentedon Dec 9, 2017
To be clear: ts-loader does not package up Typescript. It uses either the version of Typescript installed in your project, or failing that, if Typescript is globally installed that will be used.
elldritch commentedon Dec 9, 2017
I futzed around with my global TypeScript installation and got the error warnings to match. My working theory is that my
tscwas using the global installation which was at a different version than thetypescriptinstalled locally as adevDependency.luke-j commentedon Apr 23, 2018
Any update on this? TypeScript is not installed anywhere else on my system and it's not particularly obvious to me what could be causing this. Currently on
webpack@4.5.0,typescript@2.7.2&ts-loader@4.2.0with node8.11.0.johnnyreilly commentedon Apr 23, 2018
I'm afraid I don't have time to look at this myself right now. I'd hugely value someone else taking a look and reporting back.
lednhatkhanh commentedon Jul 31, 2018
Hello, any updates on this?
stale commentedon Jan 19, 2019
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
stale commentedon Jan 26, 2019
Closing as stale. Please reopen if you'd like to work on this further.
edbentley commentedon Feb 9, 2021
In case this helps anyone having this problem: I had a types conflict error because I had the same package installed in different places in a monorepo (even though they were both at the same version).
tscdidn't give me any type errors but webpack's module resolution was.