Webpack watch with AOT, builds are inconsistent

[henk23]

Bug Report or Feature Request (mark with an x)

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

Possibly related to #11835.

Command (mark with an x)

- [x] @ngtools/webpack / AngularCompilerPlugin (Hope this issue belongs here since https://www.npmjs.com/package/@ngtools/webpack links to this repo)
- [ ] new
- [ ] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Versions

node version: v8.12.0
npm version: 6.4.1
webpack version: 4.20.2
OS: macOS Sierra 10.12.6
Angular CLI: not used

Repro steps

1. Checkout minimal test repo: https://github.com/henk23/webpack-bug-test
2. Install dependencies and run webpack: npm install && node_modules/.bin/webpack -d -w
3. Open a local web server in the dist directory to load the resulting index.html. The app should load fine and display something in the console.
4. Change and Ctrl+S in any project file triggers 2nd build. Everything should still be fine.
5. Change and Ctrl+S in any project file triggers 3rd build. There will be an error in the browser console now: "Error: AngularJS v1.x is not loaded!"

The log given by the failure

There is no error in the build process. But you can see the line

[./src/app/app.module.ngfactory.js] 6.98 KiB {main} [built]

in the output of the 3rd build which is unexpected since the module was not changed and the line does not appear in the 2nd build.

Desired functionality

The resulting app should be the same on every consecutive build.

Mention any other details that might be useful

Downgrading any of the dependencies to 6.1.1 or even 6.0.0 as suggested in #11835 does not resolve the issue.
The issue does not appear when using JIT with skipCodeGeneration: true in the AngularCompilerPlugin.

[filipesilva]

The AOT compiler actually performs some extra changes over the first few rebuilds as an rebuild optimization, so the [./src/app/app.module.ngfactory.js] 6.98 KiB {main} [built] message is expected.

However, you also mention Error: AngularJS v1.x is not loaded!.

That's a runtime error that only really happens when using upgrade. I've seen it before myself and it seems mostly a timing issue. It's tricky to have upgrade load at the right time.

Right now I think this isn't really a bug in Angular CLI but actually related to ngUpgrade.

@gkalpak @petebacondarwin WDYT?

[gkalpak]

I doubt it is an ngUpgrade issue, since it works for some builds but not for others. AFAICT, the scripts are loaded through static imports, so the order should be deterministic, right?

[clydin]

Something to keep in mind is that webpack will move all imports to the top of the file. If there is any side effect causing code in the original file before an import, it will be run after the import in the final bundle.

[henk23]

Thanks, @filipesilva for looking into it. My issue is not the ngUpgrade error, but the fact that the first two builds differ from the third. Do you think the AOT optimizations could change the timing of the code in such a significant way?

And thank you too, @clydin for pointing that out. However in the test repo, all the imports are at the top of the files.

[filipesilva]

@gkalpak I've seen ngUgrade race conditions depending on how the bootstrap is setup back when I was working on ngUpgrade docs. But that was some 2 years ago or more.

@henk23 no, whatever changes in the AOT rebuilds should not change the behaviour.

[gkalpak]

Unless you refer to e2e tests (where the nature of race conditions is different), I don't know what race conditions there could be with ngUpgrade 😕
Could we somehow compare the generated code between runs and see what chnges in the 3rd one?

[filipesilva]

@gkalpak this is the problem I was remembering: angular/angular#13060. It was a while ago. Details are fuzzy in my head 😄

[henk23]

@gkalpak I put the generated code in this gist: https://gist.github.com/henk23/0a3b2c77b12543f9934220bfbb0e5dfe/revisions

Created: First build

1. revision: Second build
2. revision: Third build

Changes in line 6695 are mine. Changes in line 6659 are not.

[gkalpak]

Interesting. The changes on line 6659 don't seem related to the actual changes on line 6695 (but I know very little about webpack internals).
@filipesilva can surely make better sense of that file than me 😁

[filipesilva]

The line 6659 changes are part of how the AOT compiler changes some things around in the first few rebuilds.

I tried following the repro and can confirm that after the second rebuild, all rebuilds will show the error below:

errors.ts?a631:12 ERROR Error: AngularJS v1.x is not loaded!
    at Object.noNg (angular1.ts?8210:218)
    at module$1 (angular1.ts?8210:282)
    at UpgradeModule.bootstrap (upgrade_module.ts?483b:172)
    at eval (app.module.ts?6402:37)
    at ZoneDelegate.invokeTask (zone.js?d135:419)
    at Object.onInvokeTask (ng_zone.ts?9664:217)
    at ZoneDelegate.invokeTask (zone.js?d135:419)
    at Zone.runTask (zone.js?d135:188)
    at ZoneTask.invokeTask (zone.js?d135:496)
    at ZoneTask.invoke (zone.js?d135:485)

Further rebuilds always showed this error, and even fiddling with the timing of this.upgrade.bootstrap() did not make it go away.

I'm not sure why this happens. But I can say @ngtools/webpack doesn't really change any file in between builds. @angular/compiler (the AOT compiler, which @ngtools/webpack uses) does though, which also explains why ./src/app/app.module.ngfactory.js is shown as changing.

If I had to bet, perhaps the AOT compiler breaks ngUpgrade when it does the rebuild optimizations. I think you should report this issue in https://github.com/angular/angular since that is where @angular/compiler is developed. This repro should be fine there I think. It's a good and consistent repro.

[alan-agius4]

Hi all, it seems the reproduction provided in the original issue is no longer available.

If the problem persists, please file a new issue and provide a new reproduction.

Thanks.

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