Angular-cli: Angular-cli doesn't watch for ALL files correctly.

[montella1507]

Bug Report or Feature Request (mark with an x)

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

Versions.

@angular/cli: 1.4.2
node: 7.5.0
os: win32 x64
@angular/common: 4.4.4
@angular/compiler: 4.4.4
@angular/core: 4.4.4
@angular/forms: 4.4.4
@angular/http: 4.4.4
@angular/platform-browser: 4.4.4
@angular/platform-browser-dynamic: 4.4.4
@angular/router: 4.4.4
@angular/cli: 1.4.2
@angular/compiler-cli: 4.4.4
typescript: 2.2.2

Repro steps.

watch bug.zip
1) npm install
2) ng serve
3) change anything in src/app/store/application-state.ts (it is linked in component, which is used in app.module.ts) and SAVE = NO REBUILD
4) Change (example) from storeData: string; to storeData: boolean; and RE-SAVE anything else where the watch is correctly watching = application successfully built, but it SHOULD NOT, because there is assignment:
store.subscribe(x=> x.storeData = "pepa") but type of storeData has been changed to boolean...

Desired functionality.

It should watch for all files correctly

Mention any other details that might be useful.

• I have tried to change typescript to 2.4.0+ (because of breaking change in CHANGELOG) = NOT WORKING

• i have tried to update globally angular-cli(1.4.5) and create new APP via ng new = with latest dependencies = NOT WORKING

BTW even with latest Angular-cli, typescript version in dev-dependencies is "~2.3.3" despite your required version in CHANGELOG

[montella1507]

watch-bug-latest-cli.zip

Here is the SAME application, but generated with latest Angular-cli (1.4.5 -> ng new blabla), the same problem.. Application data is not being watched.

[montella1507]

Might be related to:
https://github.com/TypeStrong/ts-loader/issues/156 but it was fixed months ago..

And:
https://github.com/Realytics/fork-ts-checker-webpack-plugin/issues/36

But i have found this:
https://github.com/angular/angular-cli/issues/5404#issuecomment-334542578

so it may be actually a problem.

[hansl]

Closing this as duplicate of #7963

[montella1507]

@hansl what? this is definitely not truth! my problem is connected to:
Realytics/fork-ts-checker-webpack-plugin#36
and strongly connected to interfaces...

https://github.com/angular/angular-cli/issues/7963

is different.

[hansl]

After investigating, you're correct in your assumption that it's not the same issue.

The problem is 3 fold:

1. TypeScript discards type information, and since you're only importing types that file will be discarded from the compilation output;
2. Since it's discarded from the output, Webpack does not know about the dependency between your file and the TypeScript that includes the type.
3. We rely on Webpack's dependency graph to actually know if something needs rebuilding.

The only point where we actually have control is point 3 and we should look at dependencies inside TypeScript and tell webpack about TS's dependency graph. I'll come up with a fix soon.

[PierreDuc]

@hansl This fix slowed down my rebuild time exponentially. Where it usually takes 5 seconds, it takes 30-50 seconds now. I do understand that you can be more sure that things will be reanalysed now, because I also faced some issues sometimes when changing an interface for instance. But I rather have a fast rebuild, and for those rare cases a restart of ng serve, than having to wait this long for every rebuild.

Worth to mention that this rebuild is on a big application.

[filipesilva]

@PierreDuc what versions of Angular and CLI are you using? It's definitely not intended that the rebuild times increase like that.

[PierreDuc]

@filipesilva I was using 1.4.6 of the cli, but noticed an immediate increase in rebuild time. Reverted back to 1.4.5 fixed that issue. My angular version is 4.4.4. (waiting for flex-layout to update, so I can go to angular 5)

[filipesilva]

I'll take a look and try to get some numbers to benchmark. Thank you.

[filipesilva]

I can definitely reproduce. In Angular.io it increased the JIT recompile time from 420ish to 2000ms (ng2/4) and 420 to 810 (ng5, we use a new compilation pipeline).

[PierreDuc]

Yes, looking forward to using ng5, unfortunately I have to wait. But good thing you can reproduce it. I'll wait patiently for a fix. Or perhaps as a long time user of your cli, it might be time to contribute something ;)

[filipesilva]

I'm looking at it now myself, this is a pretty bad regression... we might have to revert this change if I can't come up with a fix.

[filipesilva]

@PierreDuc are you on windows? I found a fix that seems to indicate this is a windows only issue.

[filipesilva]

https://github.com/angular/angular-cli/pull/8023 is the fix I think.

[PierreDuc]

@filipesilva I'm indeed on windows. Is there a way for me to check this fix? And how come changing the path separator increases performance? Either way, thanks for the quick fix!

[filipesilva]

Inside typescript, we always use / as a path separator. This works on both windows and linux because node doesn't particularly care. We were adding paths with / to the webpack dependencies for each module, which suddenly doubled the because webpack expected \ as separator on windows.

You can test that fix by installing 1.4.6, opening ./node_modules/@ngtools/webpack/src/loader.js and doing the replacements in that PR. Bear in mind the lines won't match since the .js file was compiled from the .ts source. I'd appreciate you testing if you have the time!

[PierreDuc]

I figured that would be the way to test it, but I just couldn't find those lines of codes in there.

I've cleared the npm cache now, removed node_modules, removed package-lock.json and reinstalled the dependencies, but nowhere inside loader.js is there something remotely close to getDependencies. Nor anywhere in the @ngtools/webpack package. The version of it is 1.7.3

[filipesilva]

Ok so I'm looking at the file online in https://unpkg.com/@ngtools/webpack@1.7.3/src/loader.js. You're right, it's quite different. We published stable (1.7.3) but also the beta (1.8.0-beta.4), and a lot of code in that PR is only for the beta.

What you want to change is:

// from
            _getImports(refactor, compilerOptions, plugin.compilerHost, plugin.moduleResolutionCache)
                .forEach((importString) => this.addDependency(importString));
// to
            _getImports(refactor, compilerOptions, plugin.compilerHost, plugin.moduleResolutionCache)
                .forEach((dep) => this.addDependency(dep.replace(/\//g, path.sep)));

This should be enough to test.

[PierreDuc]

Ah yes, of course. I forgot about the different versions. Anyways, the rebuild time went from 35 seconds to 3 seconds after applying your fix. Not entirely sure, but it 'seems' to fix it ;). Nice catch!

[filipesilva]

Glad to hear this was it!

[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._}