at-loader does not display checking errors

[johnbendi]

at-loader just leaves me with the following ambiguous error message:

[at-loader] Checking started in a separate process...

[at-loader] Checking finished with 5 errors

[AlexGalays]

I have the same issue with the latest version (3.0.0-beta.18) and webpack 2.2 rc3.

It always works the very first time, and sometimes it continues to work for a while but once it get stuck with the above message, I have to restart the watch. That's a big blocker.

[kristaps]

May be something different but when using watch I get a listing of all errors on the first compile, and only the "finished with x errors" summary on subsequent compiles.

[kristaps]

Versions: awesome-typescript-loader@3.0.0-beta.18, typescript@2.1.5, anything else that could help?

[tony-gutierrez]

+1, this is killing me.

[AlexGalays]

ts-loader works just fine with webpack 2 by the way, if you're stuck.

[coffius]

+1

[ghost]

I can see error detail in browser console.

[erikstoff]

+1

[s-panferov]

Hello everybody, could you please try the latest version? Or could someone please create a repo? I have output tests and everything seems to work fine.

[jvanbruegge]

For me it happens only with the webpack 2 node API, with the cli everything works fine

[s-panferov]

If you run webpack by hand, the loader acts in non-watch mode and simply pushes all the errors to webpack.

https://github.com/s-panferov/awesome-typescript-loader/blob/master/src/instance.ts#L380-L384

You should expect to see the errors in webpack stats.

[dannypule]

Getting same issue "[at-loader] Checking finished with 12 errors". Doesn't show a list of errors in the command line. Only shows me what the errors are when I run. In my case, certain dependencies hadn't been installed (angular 2 cookie and redux) because I had done this before updating my angular starter applications package.json from it's original repo.

In other words: run your app on localhost and check whats in the console. Might give some clues.

[samal-rasmussen]

I had transpileOnly: true in my at-loader options. Changed it back to false, and got the errors back.

[davidmoshal]

+1

[davidmoshal]

same problem: at-loader: 3.0.8, webpack 2.2.1 updated to: 3.12 / 2.3.2 and problem persists. ts-loader has same problem. in both cases errors are reported to browser console, but not terminal.

[dennisat]

same problem: at-loader: 3.1.3 webpack 2.4.1 at least when I run tsc -watch I got the errors

[ythecombinator]

Still the same problem here 😢

Tried setting transpileOnly to false–as suggested by @samal84–but still no changes.

Using: at-loader: 3.1.3 and webpack 2.4.1

[ilyes-garifullin]

I have faced with the same issue and I made a temporary solution:

1. go to node_modules/awesome-typescript-loader/dist/checker

2. open runtime.js file

3. find statement if (allDiagnostics.length) { console.error(colors.red("\n[" + instanceName + "] Checking finished with " + allDiagnostics.length + " errors")); }

4. add allDiagnostics.map(function(err) { console.error(colors.red(err.messageText)); }) right after console.error call inside if (allDiagnostics.length) statement

I will be glad if this help to someone else.

[Blackbaud-SteveBrush]

@ilyes-garifullin I wonder if your fix merits a PR? Thanks for the tip!

[bsoulier]

Just added the filename, makes it easier to find the error: allDiagnostics.map(function (err) {console.error(colors.red(err.file.fileName + ':' + err.messageText)); });

[pisrael]

Same problem here. Not being able to see the errors with webpack --watch.

[davidm-public]

+1

[davidm-public]

Thanks @bsoulier This worked for me:

allDiagnostics.map( function (err) {
   console.error(colors.red(err.file.fileName + ':' + err.messageText)); 
});

"awesome-typescript-loader": "^3.1.2",
"typescript": "^2.2.2",
"webpack": "^2.4.1",

[pisrael]

At version 3.2.1 it changes a bit

"awesome-typescript-loader": "^3.2.1"

1. go to node_modules/awesome-typescript-loader/dist/instance.js

2. find statement

console.error(colors.red("\n[" + instanceName + "] Checking finished with " + diags.length + " errors"));

3. Add right below it (inside the same if)

diags.map( function (diag) {
     console.error(colors.red(diag.pretty)); 
})

[hdpinto]

Is anything being done about this? I'm still having this issue and it's now September.

[arthens]

I'm trying atl and ran into this problem too. I can always "fix" it by introducing a new error (e.g. removing an import). For some reason this causes the errors to start working again.

Initially I thought it simply didn't show the errors if they were the same or a subset of the previous compilation (which would explain why a introducing a new error fixes it), but after using it for a few days I'm not sure anymore...

[arthens]

Ok I did a bit of investigation and realised it was a configuration problem, I'm going to post it in case anyone else did the same mistake.

tl;dr I was not using CheckerPlugin, which caused asyncError to be disabled. Adding the plugin fixed my problem.

Longer explanation: atl requires CheckerPlugin to detect watch mode. If not in watch mode (or in watch mode but no plugin enabled) it will send the errors to webpack instead of printing them.

However, webpack will only print errors after bundling assets, but based on the change (and possibly your webpack configuration?) it might decide that no bundling is required, and skip printing errors. A few example of changes that would not trigger webpack:

• changing a typescript method signature
• adding/removing a type

• new lines

  This is because these changes are only relevant to TypeScript. Types are removed when the file is compiled to javascript. The compiled version will look unchanged to webpack... which will probably skip compilation and printing errors.

[winston01]

@arthens I added CheckerPlugin and set watch: true in webpack.config.js, but I still can't see the error details. Can you add a sample of your config file?

[arthens]

@winston01 not sure how useful it's going to be, but here it is

[timc13]

This is still a problem - CheckerPlugin or not

[riq-dfaubion]

CheckerPlugin bandaided the problem for me as well.

[djyde]

Same problem!

[djyde]

almost two years. No one fix this problem?

[alienriver49]

I think the pull request, #437, is a bit old compared to the latest in the repository since this is now using webpack-log to log information. In order to fix this now you'll want to find this in the runtime.js file:

function processDiagnostics(_a) {

Go to the end of the function and add this line:

processedDiagnostics.forEach(function (diag) {
    log.info(diag.pretty);
});

I'll look into creating a new pull request for changes similar to this.