Angular-cli: ng serve produces error randomly

[bunyaminsg]

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Versions.

@angular/cli: 1.0.0
node: 6.10.1
os: linux x64
@angular/animations: 4.0.0
@angular/cli: 1.0.0
@angular/common: 4.0.0
@angular/compiler: 4.0.0
@angular/compiler-cli: 4.0.0
@angular/core: 4.0.0
@angular/forms: 4.0.0
@angular/http: 4.0.0
@angular/platform-browser: 4.0.0
@angular/platform-browser-dynamic: 4.0.0
@angular/platform-server: 4.0.0
@angular/router: 4.0.0
@ngtools/webpack: 1.3.0

Repro steps.

    ng serve

The log given by the failure.

Module build failed: Error
    at WebpackCompilerHost.populateWebpackResolver (/home/bunyamin/WebstormProjects/c3dp/node_modules/@ngtools/webpack/src/compiler_host.js:135:51)
    at _donePromise.Promise.resolve.then.then.then.then.then (/home/bunyamin/WebstormProjects/c3dp/node_modules/@ngtools/webpack/src/plugin.js:366:32)
    at process._tickCallback (internal/process/next_tick.js:109:7)
 @ ./src/app/patient/patient-care-plan/index.ts 2:0-105
 @ ./src/app/patient/patient.module.ts
 @ ./src async
 @ ./~/@angular/core/@angular/core.es5.js
 @ ./src/main.ts
 @ multi webpack-dev-server/client?http://localhost:4200 ./src/main.ts

Desired functionality.

The project does not contain any error and works well. However, it gives the error above when it recompiled at some random moments.

Mention any other details that might be useful.

The most obvious example of this bug: I was working on my project (there were no errors) and I added just a comment like // some comment and it gave the error when recompiled. Then, I stopped and re-run the ng serve command and there were no error this time.

[filipesilva]

I tried adding the comment and couldn't see the error myself. Leaving this open but without a reliable repro we're not able to fix it.

[bunyaminsg]

@filipesilva that is the problem actually. It is the expected behaviour to not give error on comment. I don't think it is because of the comment, I just give it as an example to point how strange it gives error sometimes. I faced these errors sometimes even when I added just a space and saved. I thought something is wrong with versions of packages, but I couldn't fix it. I had to exit ng serve with CTRL + C signal and re-run the command several times yesterday. The error may disappear when recompiled or I might have to recompile it several times until the error disappears.

[isaacplmann]

I'm getting the same error. It only happens for me when I save a file that's in a lazy loaded module. If I then save the app.component.ts file, the build succeeds (without needing to kill the process and restart). I haven't been able to reproduce with a demo app though.

[bunyaminsg]

For more information, I don't get the error with new projects created after updates. However, even if I updated all related packages (@angular/..., webpack, zone.js, etc.), I get the error with the old project that is started to be implemented with Angular v2.

[bunyaminsg]

@isaacplmann Increasing the watchers as mentioned in this comment seems fixed the problem for me. Can you try it and confirm if it works?

[isaacplmann]

I tried that comment, but it appears it only applies to linux. I'm using a mac. I tried what might be equivalent instructions: https://facebook.github.io/watchman/docs/install.html#max-os-file-descriptor-limits
But that didn't help either. (That link does say only applicable on OS X 10.6 and lower, and I'm on 10.11)

[bunyaminsg]

You can try to exclude node_modules in tsconfig.json. This prevents webpack to watch changes in the files of node_modules. See this comment

[isaacplmann]

No luck. I excluded node_modules in both the root tsconfig.json and tsconfig.app.json. I also tried running ulimit -S -n 20480 from here.

[metodribic]

@isaacplmann any luck with this one? I'm also experiencing the same behaviour as you and I'm on the Mac also.

[isaacplmann]

@metodribic I'm just living with it right now. It's kind of annoying, but I am able to get the app to compile as long as I remember to save a non-lazy-loaded file after I make a change to a lazy-loaded one.

[jolafrite]

Hi any news on that ?
Just updated to @angular/cli: 1.1.1 and still have the same issue

I'm on Mac
node_modules is excluded
My config :
kern.maxfiles: 10485760
kern.maxfilesperproc: 1048576
ulimit unlimited

[isaacplmann]

I came up with a hacky workaround today, since this has become annoying enough that I wanted to do something about it. Go to node_modules/@ngtools/webpack/src/compiler_host.js and comment out lines 133-135. This will obviously need to be repeated any time you reinstall node modules and will rapidly become obsolete as the cli gets updated - but it makes so that I don't have to keep remembering to save some unrelated file when I'm working.

[jolafrite]

I have tried to comment out this piece of code before.
But it might be used by webpack to refresh its file caching.
I say that because If I modify a file, webpack compilation restart and serve me with the file without my modification.
You don't have this issue ?

[isaacplmann]

@jolafrite I've been using my hack for a day now without any problems. If I run into issues, I'll report them back here.

[metodribic]

I've noticed that this occure every time I rename/refactor some files/directories. So lets say I renamed directory name and all of the components files inside it + name of the component in component.ts, module.ts and index.ts. All of this while server is running of course. Can anybody test this scenario if it raise this error, because if it does we have a reproduction steps.

Edit: Even if I rename/refactor only the directory name, the error is raised.

_Note: I'm using Webstorm 2017 for this actions. Not sure if this is important information or not..._

[bunyaminsg]

@metodribic I am also using Webstorm. However, I didn't get this error after I excluded the node_modules from tsconfig.json and increased the watchers even if I did refactoring/renaming many times.

[scott-phillips-sp]

I looked into this problem and I believe it is a race condition between the invalidating & read files for the host compilation. As a project grows bigger the chance of the race condition increase. I tried to make a reproduction using a fresh app and tried with 10 components, but that wasn't enough to reproduce the issue.

The issue is that there is a race condition invalidating a file:

Files will get invalidate here from a watch conidition:
https://github.com/angular/angular-cli/blob/master/packages/%40ngtools/webpack/src/plugin.ts#L273

They will get re-read here from the ngloader:
https://github.com/angular/angular-cli/blob/master/packages/%40ngtools/webpack/src/loader.ts#L454

However, if in between these two points the populateWebpackResolver is called it fail because the invalidate command removes the file from the cache.
https://github.com/angular/angular-cli/blob/master/packages/%40ngtools/webpack/src/compiler_host.ts#L149

I created a pull request that works for me locally with my app. It makes the change that when a file changes instead of removing it from the cache and waiting for the loader to re-load the file it will immediately re-read the changes and populate the cache.
https://github.com/angular/angular-cli/pull/6920

[filipesilva]

@hansl can you have a look at @scott-phillips-sp comment and PR?

[JaSpr]

bump

[dneeleman]

Bump bump

[ChrisGibb]

bump
.. just wanted to add this is a frustrating bug. Sometimes I can't get it to recompile at all, so then I have to terminate Karma, which closes the browser, so I loose my breakpoints. This is very annoying while trying to debug an issue.

[JaSpr]

This doesn't happen for me in just karma. Mainly if I change anything in a lazy-loaded module, I have to add/remove whitespace so that I can re-save and sometimes takes up to 10 times to build properly.

[McNull]

Same issue here. I'm on OSX and it seems to be related to lazy loading modules.

[alan-agius4]

Thanks for reporting this issue. This issue is now obsolete due to changes in the recent releases. Please update to the most recent Angular CLI version.

If the problem persists after upgrading, please open a new issue, provide a simple repository reproducing the problem, and describe the difference between the expected and current behavior.

[angular-automatic-lock-bot[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._}