You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dont know if this ever worked with @ngtools/webpack because i havent been using it during development before.
Description
When you create compilation error in project, like you add some unused import, compilation throws error in console, but this error is not displayed in WebpackNotifierPlugin nor in browser through HMR. When you use awesome-typescript-loader it works correctly.
What is even weirder is that if you stop compilation process and run it again, error is thrown correctly everywhere, only during HMR change it is not handled correctly.
If you fix initial problem and HMR is running you will get error
from the TypeScript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
and you have to restart npm start command. All three mentioned things are slowing development with @ngtools/webpack compared to awesome-typescript-loader.
git clone https://github.com/kukjevov/ngtools-error cd ngtools-error npm install npm start
open in browser http://localhost:8888 add ChangeDetectorRefintonavigation.component.ts` into import statement
save file
you can see error in system console, but no error in browser, nor in WebpackNotifierWindow
open navigation.component.ts and remove unused ChangeDetectorRef from import statement
save file
you can see error in system console, this errors dissapears after you restart npm start
1. Forked type checking errors not being sent to webpack
This seems to be caused by the forked type checker as when using the fork type checking we are solely emitting logs to the the console and not passing these logs to the webpack compilation. As a workaround you cab disbale forkTypeChecker via the AngularCompilerPlugin.
2. Compilation errors in (AOT) first run errors are not being recoverable
For the former, I am not sure if there was any reason why we solely log such error message instead of providing them in webpack compilation. Looping in @filipesilva as he probably knows.
It's intended that type errors aren't sent to webpack when using the forked type checker. If they were, and they blocked the compilation, then there's no point in having a forked type checker as rebuilds would just take longer.
I don't think it makes sense to use a separate forked TS type checker. You'd just get twice the number of TS type checks, and it wouldn't work correctly in AOT mode. It might be possible to send type errors to the HMR report in between compilations, it's just not something we've looked at.
It would be great to have some information about compilation errors at least in browser, because right now i dont know that there are errors application usually works and then on server application fails becuase there is no HMR build and i send not compilable application to repository, because i dont check console so often.
@filipesilva you know what is interesting? Sometimes, i dont know what have i done but, running @ngtools/webpack gets in state, when everything is working even AOT compilation errors are shown in notifications and also through HMR
Only difference what i see is that if it is not displayed, it is case when error is displayed in console as regular text, but if it is displayed as "error" in red it gets everywhere it should. So it means it is possible to make it working :).
@filipesilva I figured it out. Now i know what to do to make it working. If you create webpack error, like import non existing template in templateUrl and fix it and then cause any typescript or AOT binding template error it will work in notifications and also in browser using HMR.
Activity
alan-agius4 commentedon Aug 20, 2019
Hi, thanks for opening the issue.
There are separate issues here;
1. Forked type checking errors not being sent to webpack
This seems to be caused by the forked type checker as when using the fork type checking we are solely emitting logs to the the console and not passing these logs to the webpack compilation. As a workaround you cab disbale
forkTypeCheckervia theAngularCompilerPlugin.2. Compilation errors in (AOT) first run errors are not being recoverable
For the former, I am not sure if there was any reason why we solely log such error message instead of providing them in webpack compilation. Looping in @filipesilva as he probably knows.
filipesilva commentedon Aug 20, 2019
First run errors AOT should be recoverable. It sounds like a bug that they aren't.
alan-agius4 commentedon Aug 20, 2019
Yeah, that for sure, what about the first problem?
filipesilva commentedon Aug 20, 2019
It's intended that type errors aren't sent to webpack when using the forked type checker. If they were, and they blocked the compilation, then there's no point in having a forked type checker as rebuilds would just take longer.
kukjevov commentedon Aug 20, 2019
Thanks for answers.
Could be part of first problem solved by using https://www.npmjs.com/package/fork-ts-checker-webpack-plugin for notifications?
Is there any way to be able to send these errors to HMR report in browser without disabling forkedTsCheck?
filipesilva commentedon Aug 20, 2019
I don't think it makes sense to use a separate forked TS type checker. You'd just get twice the number of TS type checks, and it wouldn't work correctly in AOT mode. It might be possible to send type errors to the HMR report in between compilations, it's just not something we've looked at.
kukjevov commentedon Aug 20, 2019
It would be great to have some information about compilation errors at least in browser, because right now i dont know that there are errors application usually works and then on server application fails becuase there is no HMR build and i send not compilable application to repository, because i dont check console so often.
Thanks
kukjevov commentedon Sep 9, 2019
@filipesilva you know what is interesting? Sometimes, i dont know what have i done but, running @ngtools/webpack gets in state, when everything is working even AOT compilation errors are shown in notifications and also through HMR
Only difference what i see is that if it is not displayed, it is case when error is displayed in console as regular text, but if it is displayed as "error" in red it gets everywhere it should. So it means it is possible to make it working :).
kukjevov commentedon Sep 9, 2019
@filipesilva I figured it out. Now i know what to do to make it working. If you create
webpackerror, like import non existing template intemplateUrland fix it and then cause any typescript or AOT binding template error it will work in notifications and also in browser using HMR.Thanks
alan-agius4 commentedon Nov 5, 2020
Hi @kukjevov,
This should be addressed via #19114
kukjevov commentedon Nov 5, 2020
Hi @alan-agius4 will this land in version 11?
Thx anyway :)
alan-agius4 commentedon Nov 5, 2020
That would be available in 11.1
angular-automatic-lock-bot commentedon Dec 6, 2020
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.