NGCC create-ivy-entry-points for all project libraries before parallel test

We based our new build pipeline on standard ng cli commands. Especially for parallel builds, we create a dependency tree reading library’s package.json file and run ng build command on our libraries in a parallel way.

For this particular task, the ngcc call before all compilation steps works like a charm (see https://angular.io/guide/ivy#speeding-up-ngcc-compilation).

The main problem now is that we would like to run tests also on parallel way after we build our libraries. Actually, ng test libraryName command, just tries to compile in ‘ivy’ way all our libraries it depends on, every time we execute tests.

Running our CI pipeline with a sequential test approach doesn’t raise errors (but it is slower). Feature requested is just related to a way to compile our project libraries on dist folder in ‘ivy’ way before run tests to support also parallel tests.

See for example error from our teamcity agent:

Start to test projects parallel with 4 cpus
08:13:46
    Start test of @aulos/core with dependencies: []
08:13:46
    Start test of @aulos/common with dependencies: []
08:13:46
    Start test of @aulos/common-validators with dependencies: []
08:13:55
    JavaScript Unit Tests
08:13:55
      18 03 2020 08:13:55.510:INFO [karma-server]: Karma v4.2.0 server started at http://0.0.0.0:9877/
08:13:55
      18 03 2020 08:13:55.526:INFO [launcher]: Launching browsers ChromeHeadless with concurrency unlimited
08:13:55
      18 03 2020 08:13:55.545:INFO [launcher]: Starting browser ChromeHeadless
08:13:55
      JavaScript Unit Tests
08:13:56
      ERROR in ngcc is already running at process with id 4565.
08:13:56
      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;
08:13:56
      See https://v9.angular.io/guide/ivy#speeding-up-ngcc-compilation
08:13:56
      (If you are sure no ngcc process is running then you should delete the lockfile at /opt/teamcity-agent/work/d27e3f1950cca49c/node_modules/@angular/compiler-cli/ngcc/__ngcc_lock_file__.)
08:13:56
      End test process of @aulos/core with code 1
08:13:56
      We have to test 3 libraries with 2 free cpu.
08:13:56
      Start test of @aulos/security with dependencies: [@aulos/core]
08:13:56
      Start test of @aulos/globalization with dependencies: [@aulos/core]
08:13:56
      Start test of @aulos/binary-resources with dependencies: [@aulos/core]
08:13:59
      
08:13:59
      Compiling @aulos/common : es2015 as esm2015
08:14:01
      18 03 2020 08:14:01.074:INFO [karma-server]: Karma v4.2.0 server started at http://0.0.0.0:9878/
08:14:01
      18 03 2020 08:14:01.075:INFO [launcher]: Launching browsers ChromeHeadless with concurrency unlimited
08:14:01
      18 03 2020 08:14:01.084:INFO [launcher]: Starting browser ChromeHeadless

As you can see we run 3 concurrency tests but they require building our libraries (for example @aulos/common).

So request here is to enable ngcc ..... --create-ivy-entry-points also on ./dist/libraries folders.

[petebacondarwin]

I have a fix in the works. See #36180

[petebacondarwin]

The improvements to CLI+ngcc integration were to run ngcc in async mode across the node_modules before running the build, where ngcc can only be run in sync mode. The benefits of async mode are: slight performance improvement if tasks can be run in parallel; and ability for ngcc to pause and wait (rather crashing) if another build is running ngcc.

This new integration is not able to build packages that are not in node_modules (e.g. in dist) as in this scenario since at that point it does not have access to the path mappings etc. So in your case you still need to run ngcc against the dist folder before running ng build if you want to run the builds in parallel. (If the builds are not parallel then there is no problem because the sync CLI+ngcc integration can handle dist packages.

If we implement ngcc looking up a local tsconfig.json when in async parallel mode then it might be that the new async CLI+ngcc integration might be able to handle this scenario too!