Original TS internal error is hidden #824
Comments
|
Thanks for the detailed issue; that's always helpful. Do you have any insight as to what you feel a sensible workaround would look like? |
|
I was a bit stymied figuring out where the original error got swallowed, the debugger stops in what looks like regenerator-runtime code with no user code on the stack. My guess is that either you or webpack are catching the exception to be reported later, but this hook is being fired first. If so, adding a flag tracking that an error was thrown so you know not to call back in should be enough? |
|
Just had a thought. Is this specifically related to That's not supported in ts-loader yet, but hopefully will be: #817 |
|
No, #793 was originally caused by a TS 2.9 bug microsoft/TypeScript#24932 It's true the case I care about is triggered when the target project is |
Could you share a link to that please? I'd love to read.
Roughly speaking you can track where errors are propogated by looking for https://github.com/TypeStrong/ts-loader/search?utf8=✓&q=_module.errors.push&type= Does that help?
Why don't you submit a PR to show me what you have in mind? Don't worry about tests for now; just something to illustrate what you're thinking of. We can use that as a basis for discussion / potential implementation. |
|
Here's the handbook page on project references. The structure I mentioned is described in the "Guidance" section at the bottom. Messed around with the code for a bit, here's a hacky-looking fix: diff --git i/src/after-compile.ts w/src/after-compile.ts
index 5ba828d..8e71b73 100644
--- i/src/after-compile.ts
+++ w/src/after-compile.ts
@@ -19,6 +19,10 @@ export function makeAfterCompile(
let checkAllFilesForErrors = true;
return (compilation: WebpackCompilation, callback: () => void) => {
+ if (compilation.errors.length) {
+ callback();
+ return;
+ }
// Don't add errors for child compilations
if (compilation.compiler.isChild()) {
callback();Which gives the desired root error: So webpack was the one catching the error and adding it to the compilation errors list (which makes sense), but when the hook threw, it essentially replaced the error list (which is pretty lame). Not quite sure what the right behavior is here, a slight better hack fix would be to catch any errors in the hook and push them to the errors list, but I think the right thing to do is to try to somehow distinguish non-exceptional errors (like user TS errors) and internal errors which might indicate that the compiler is "poisoned", but I don't know what that would look like. Also, it does look like microsoft/TypeScript#26554 requires the project requires the target project to have both |
This is a pretty hacky fix for TypeStrong#824
|
Please bear with me as I'm away from home right now with only access to my phone and poor connectivity. Debugging in my head is difficult!
Isn't this what already happens? Or rather, reading through the hook logic I see the old TypeScript errors being removed but I don't see this happening:
I don't follow how that happens? |
|
It's webpack that essentially replaces, by printing the new error, but not the error list. When I say "error" here, I mean a thrown exception, not a result returned from the ts error apis. Sorry, this is a bit confusing to talk about! |
|
Added a PR if you missed it; in case that's easier for you? |
|
Thanks I'll take a look |
|
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. |
|
Closing as stale. Please reopen if you'd like to work on this further. |
Pulled out a more specific request from #793
Expected Behaviour
When hitting (certain) internal TS errors such as microsoft/TypeScript#24932 (TS 2.9.1) and microsoft/TypeScript#26554 (TS 3.0.1),
ts-loaderattempts to get the error diagnostics which can fail with a stack like:Actual Behaviour
The original TS error is reported, e.g. for microsoft/TypeScript#26554
Steps to Reproduce the Problem
For microsoft/TypeScript#26554, it should be enough to have a
ts-loaderconfig that looks something like:i.e. compiler options has
composite, but notrootDirset.Location of a Minimal Repository that Demonstrates the Issue.
microsoft/TypeScript#26554 (comment) links to a reproducing case.
The text was updated successfully, but these errors were encountered: