Angular 9 - ngcc is already running

[bolrock]

🐞 bug report

Description

I have an angular 9 workspace with 2 projects:

• a libary
• a showcase application for testing the library while developping it

So I'm doing a ng build my-library --prod --watch followed by npm start showcase.
The first on is going right but the second one fails with

chunk {main} main.js, main.js.map (main) 2.04 kB [initial] [rendered]
chunk {polyfills} polyfills.js, polyfills.js.map (polyfills) 699 bytes [initial] [rendered]
chunk {runtime} runtime.js, runtime.js.map (runtime) 6.15 kB [entry] [rendered]
chunk {styles} styles.js, styles.js.map (styles) 10.6 kB [initial] [rendered]
chunk {vendor} vendor.js, vendor.js.map (vendor) 341 kB [initial] [rendered]
Date: 2020-02-12T08:31:44.330Z - Hash: 2061194b646fd4602d5d - Time: 2009ms

ERROR in ngcc is already running at process with id 13848.
If you are running multiple builds in parallel then you should pre-process your node_modules via the command line ngcc tool before starting the builds;
See https://v9.angular.io/guide/ivy#speeding-up-ngcc-compilation.
(If you are sure no ngcc process is running then you should delete the lockfile at .../node_modules/@angular/compiler-cli/ngcc/ngcc_lock_file.)
** Angular Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200/ **

🌍 Your Environment

Angular Version:

Angular CLI: 9.0.1
Node: 12.15.0
OS: win32 x64

Angular: 9.0.0
... animations, cdk, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace: Yes

Package Version

@angular-devkit/architect 0.900.1
@angular-devkit/build-angular 0.900.1
@angular-devkit/build-ng-packagr 0.900.1
@angular-devkit/build-optimizer 0.900.1
@angular-devkit/build-webpack 0.900.1
@angular-devkit/core 9.0.1
@angular-devkit/schematics 9.0.1
@angular/cli 9.0.1
@angular/flex-layout 9.0.0-beta.29
@ngtools/webpack 9.0.1
@schematics/angular 9.0.1
@schematics/update 0.900.1
ng-packagr 9.0.0
rxjs 6.5.4
typescript 3.7.5
webpack 4.41.2

[splincode]

@bolrock please, create a minimal reproduction (github repo with reproduction steps)

[bolrock]

While trying to write some code like @splincode asked me, I looked more deeply to what's happening.

I first deleted the node_modules/@angular/compiler-cli/ngcc/ngcc_lock_file

I I then noticed

• when launching ng build my-library --prod --watch the ngcc_lock_file is not created.
• when launching npm start showcase the ngcc_lock_file is created but deleted a while after.

So I supposed that the file was not correctly erased and that the 'conflict' is not coming from the library build watch but from a previous ng serve which did not erased the lock file.

[gkalpak]

Thx for the update, @bolrock 👍
While we try to always clean up the lockfile before the process exits, it is indeed possible that we might fail to do so (e.g. if a process crashes).

It sounds like this can be closed, right? (Comment below to correct me if not.)

[kylecordes]

This situation occurs even when:

• You are not starting out with a leftover lock file.
• You have run the ahead-of-time ngcc is recommended in the documentation.
• You do a lot of parallel building.

I don't think it has to do with any particular project, so it's hard to come up with a project that reproduces it per se. Though maybe an example that just creates 100 stub projects in the workspace and then uses the "parallel" command to build them in parallel, might reliably reproduce it?

It seems to me there is some issue with the ngcc logic. Perhaps the build process always tries to take a lock briefly, and thus creates a race condition. Perhaps the ahead of time ngcc does not produce exactly the output that a later build will need to avoid the warning.

[kylecordes]

Also: in the current behavior, the build exits with an error upon finding this problem. That seems unnecessarily fragile. Shouldn't it do some kind of exponential back off retry for a few seconds at least before giving up?

[gkalpak]

@kylecordes, this sounds like a different problem (same symptom, different root cause). Feel free to open a new issue.

With #35131, ngcc will be able to wait for other processes to complete. However, it still not possible to take advantage of this when running via the CLI, because the CLI hooks into TypeScript's module resolution and thus has to run ngcc synchronously (TS module resolution is synchronous).

We have plans to make CLI take advantage of running ngcc async (e.g. as a pre-build step/pass), but nothing concrete yet. So, atm, if you want to run multiple CLI builds in parallel, you have to run ngcc upfront. Also, in order for this to work, ngcc nas to be run with appropriate arguments to ensure that it will compile the same targets that the CLI will need for building later. (This depends on the project's config, though.)

[kylecordes]

@gkalpak Very good, thank you for the explanation.

Since there is work already underway, I will wait for the next patch version or two and see what happens then submit an issue.

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