-
-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build passes if some import has filename with different case #289
Comments
Does this behave differently when you change |
Nope, behaviour is same, whether it |
Oh, no, sorry, I've tested wrongfully. Setting |
Ah. What happens if you combine |
Aha, build fails!
|
So this is an interesting edge case. Just to give you some background on this: Their version does an early exit if a syntactic error is found and will not emit any other kind of error. But as usually ts-loader already reports syntactic errors, we don't emit those by default so that you don't see this error twice. So you neither get an error nor an indication that an error might have been seen, but has never been looked for. With #268, the situation there was improved (syntactic errors now should not prevent the emission of semantic errors), but your error is apparently neither a I had not seen one of these in the wild until now :/ I'll try to get a PR for this running in the next days - if possible. But it might also be necessary to change the default behaviour altogether. I'm not sure for now. Anyways: it would be great if you could do some testing when I come back to this in a few days :) @johnnyreilly - do you have any thoughts on this? |
At your service, of course. Guess I should make test repo, since bug is legit. |
I too had not seen a global error in the wild either! 😁 But you can see the behaviour in the TypeScript incremental API here: To quote the comment:
So yeah, it looks like we should be catering for global errors in the same way we do for semantic errors. Oh and a test to cover this would be tremendous 🤗 |
So, made test repo https://github.com/Reeywhaar/fork-ts-checker-289 Funny enough, now I see that ts-loader behaves differently from project where I've found bug, In my project it reports all errors (type error, casing error). However, here it reports duplicated error. |
Yeah I'd expect ts-loader to be fine here. It generally doesn't use the incremental API. It has support through an (undocumented) option called |
Oh, great, this is a double-edge-case: It only fails on operating systems with case-insensitive file systems like OSX or Windows. On my Linux machine, this doesn't even get to the global error, because it already fails before that step. Gotta find a way to test that :D |
🎉 This issue has been resolved in version 1.3.4 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Current behavior
Consider we have
src/SomeLib.ts
and import it asimport {something} from "src/someLib"
.If SomeLib has type errors fork-ts-checker will give no hint about this. Even more, it completely misses all type errors in project and always builds with "no type errors found". Standard ts compiler will give errors and will warn that import filename case differs from original.
Expected behavior
Fork-ts-checker should give same errors as ts compiler
Steps to reproduce the issue
Create index.ts and lib.ts, put content to index.ts:
import {Something} from "Lib.ts"
, put content to lib.tsbuild with webpack.
Test Repository
https://github.com/Reeywhaar/fork-ts-checker-289
Environment
Additional
tsconfig.json
The text was updated successfully, but these errors were encountered: