Skip to content

@ngtools/webpack HMR compilation errors ignored聽#15372

Closed

Description

@kukjevov

馃悶 Bug report

Command (mark with an x)

- [ ] new
- [ ] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

not using angular cli, but @ngtools/webpack

Is this a regression?

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.

馃敩 Minimal Reproduction

download this https://github.com/kukjevov/ngtools-error

#1

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

#2

stop npm start
run npm start again
you will see error in system notification window
refresh browser http://localhost:8888
you will see also in browser

#3

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

馃敟 Exception or Error

See minimal reproduction part

馃實 Your Environment

  • angular: 9.0.0-next.2
  • @ngtools/webpack: 8.3.0-rc.0
  • node: 10.16.0
  • npm: 6.9.0

Activity

  1. alan-agius4 commented on Aug 20, 2019

    @alan-agius4
    Collaborator

    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 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.

  2. modified the milestone: Backlog on Aug 20, 2019
  3. filipesilva commented on Aug 20, 2019

    @filipesilva
    Contributor

    First run errors AOT should be recoverable. It sounds like a bug that they aren't.

  4. alan-agius4 commented on Aug 20, 2019

    @alan-agius4
    Collaborator

    Yeah, that for sure, what about the first problem?

  5. filipesilva commented on Aug 20, 2019

    @filipesilva
    Contributor

    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.

  6. kukjevov commented on Aug 20, 2019

    @kukjevov
    Author

    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?

  7. filipesilva commented on Aug 20, 2019

    @filipesilva
    Contributor

    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.

  8. kukjevov commented on Aug 20, 2019

    @kukjevov
    Author

    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

  9. kukjevov commented on Sep 9, 2019

    @kukjevov
    Author

    @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 :).

  10. kukjevov commented on Sep 9, 2019

    @kukjevov
    Author

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

    Thanks

  11. alan-agius4 commented on Nov 5, 2020

    @alan-agius4
    Collaborator

    Hi @kukjevov,

    This should be addressed via #19114

  12. kukjevov commented on Nov 5, 2020

    @kukjevov
    Author

    Hi @alan-agius4 will this land in version 11?

    Thx anyway :)

  13. alan-agius4 commented on Nov 5, 2020

    @alan-agius4
    Collaborator

    That would be available in 11.1

  14. angular-automatic-lock-bot commented on Dec 6, 2020

    @angular-automatic-lock-bot

    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.

  15. locked and limited conversation to collaborators on Dec 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions