Type error only through ts-loader

[quicksnap]

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?

[johnnyreilly]

No. Do you have a different version of TypeScript in your package.json?

[quicksnap]

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

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]

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]

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]

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]

Totally understand. It's really baffling..

[elldritch]

I'm seeing weirdness too, where ts-loader's type-checking fails but tsc's type-checking succeeds. For me, the definition of RequestInit in lib.es6.d.ts:6569 is different between the two.

[johnnyreilly]

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]

I futzed around with my global TypeScript installation and got the error warnings to match. My working theory is that my tsc was using the global installation which was at a different version than the typescript installed locally as a devDependency.

[luke-j]

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 [email protected], [email protected] & [email protected] with node 8.11.0.

[johnnyreilly]

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]

Hello, any updates on this?

[stale]

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]

Closing as stale. Please reopen if you'd like to work on this further.

[edbentley]

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). tsc didn't give me any type errors but webpack's module resolution was.