angular: ngcc fails to scan directory in Azure DevOps Hosted Agent
๐ Bug report
Command (mark with an x
)
ngcc
Is this a regression?
Unsure, weโre using a different command than previously.
Description
After upgrading to Angular 9.1, the ngcc
postinstall script no longer compiles projects in our node_modules
folder.
The release changelog for Angular 9.1 mentions changes to running the ngcc
command. Angular.io states the postinstall
script should be โngccโ (changing from ngcc --properties es2015 browser module main --first-only --create-ivy-entry-points
).
When this runs on local development machines (Windows, and WSL), the node_modules folder is scanned and Angular Material et. al are built in the various formats (esm2015
, esm5
, etc).
Our CI system runs in Azure DevOps on Linux Hosted (ubuntu 18.04, x64) agents. When the postinstall script runs there, the command completes immediately with no targets compiled. The various libs and such are compiled when we run ng [build|test] --project=[blah]
commands however. We cache our node_modules
install so we can farm out the test, build steps for the multiple projects in our workspace in parallel more quickly. In 9.0, the cache would include the pre-compiled projects, but with 9.1 those are no longer in the cache, causing our CI build to take much longer.
๐ฌ Minimal Reproduction
- set up package.json with specified
postinstall
script, targeting Angular 9.1 & Material 9.2 - npm ci
๐ฅ Exception or Error
The build output will say it invokes ngcc
, but nothing is compiled. We also tried running ngcc
with --async false
with the same results.
We ran the command with -l debug
and saw this output:
Debug: Forking unlocker child-process
Debug: Attemping to write lock-file at /home/vsts/work/1/s/node_modules/@angular/compiler-cli/ngcc/__ngcc_lock_file__ with PID 3261
Debug: Written lock-file at /home/vsts/work/1/s/node_modules/@angular/compiler-cli/ngcc/__ngcc_lock_file__ with PID 3261
Debug: Running ngcc on SingleProcessExecutorSync.
Debug: Analyzing entry-points...
Debug: No manifest found for /home/vsts/work/1/s so walking the directories for entry-points.
Debug: Walking directories took 0s.
Debug: Analyzed 0 entry-points in 0s. (Total tasks: 0)
Debug: Processing tasks...
Debug: Processed tasks in 0s.
Debug: Attempting to remove lock-file at /home/vsts/work/1/s/node_modules/@angular/compiler-cli/ngcc/__ngcc_lock_file__.
Debug: PIDs match (3261), so removing /home/vsts/work/1/s/node_modules/@angular/compiler-cli/ngcc/__ngcc_lock_file__.
Debug: Run ngcc in 0s.
Debug: Starting unlocker at process 3275 on behalf of process 3261
Debug: The lock-file path is /home/vsts/work/1/s/node_modules/@angular/compiler-cli/ngcc/__ngcc_lock_file__
Debug: Attempting to remove lock-file at /home/vsts/work/1/s/node_modules/@angular/compiler-cli/ngcc/__ngcc_lock_file__.
Debug: The lock-file at /home/vsts/work/1/s/node_modules/@angular/compiler-cli/ngcc/__ngcc_lock_file__ was already removed.
๐ Your Environment
Angular CLI: 9.1.0
Node: 12.10.0
OS: linux x64
Angular: 9.1.0
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, router, service-worker
Ivy Workspace: Yes
Package Version
------------------------------------------------------------
@angular-devkit/architect 0.900.7
@angular-devkit/build-angular 0.901.0
@angular-devkit/build-ng-packagr 0.901.0
@angular-devkit/build-optimizer 0.901.0
@angular-devkit/build-webpack 0.901.0
@angular-devkit/core 9.0.7
@angular-devkit/schematics 9.0.7
@angular/cdk 9.2.0
@angular/material 9.2.0
@angular/material-moment-adapter 9.2.0
@ngtools/webpack 9.1.0
@schematics/angular 9.0.7
@schematics/update 0.901.0
ng-packagr 9.0.3
rxjs 6.5.4
typescript 3.7.5
webpack 4.42.0
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 18 (9 by maintainers)
Commits related to this issue
- fix(ngcc): handle bad path mappings when finding entry-points Previously, a bad baseUrl or path mapping passed to an `EntryPointFinder` could cause the original `sourceDirectory` to be superceded by ... — committed to petebacondarwin/angular by petebacondarwin 4 years ago
- fix(ngcc): handle bad path mappings when finding entry-points (#36331) Previously, a bad baseUrl or path mapping passed to an `EntryPointFinder` could cause the original `sourceDirectory` to be super... — committed to angular/angular by petebacondarwin 4 years ago
Marvellous! I am glad you are sorted. I am putting together a PR to ignore these missing paths and to log a warning, so it shouldnโt be such a pain to debug in the future.