Library is skipped by Ivy / ngcc compiler #40357

smnbbrv · 2020-11-23T20:53:20Z

🐞 Bug report

Command (mark with an `x`)

Is this a regression?

I'm not sure. Upgraded to angular 11 almost together with getting the issue - might be.

Description

I maintain a set of libraries to work with gRPC from Angular, here is the link: https://github.com/ngx-grpc/ngx-grpc

The lib includes 6 libs (located in packages):

one non-angular (however located between angular apps, just is not present in angular.json) - protoc plugin - protoc-gen-ng
4 normal angular libs
1 angular lib; built using Angular toolset but is used inside a web worker - worker.

There is also examples directory served as example and, well, as a test reference that all goes fine. This example uses all the libs, and this is the place where the error is happening.

Now I added a module with forRoot / forChild in some of the angular libraries: core (2 modules), grpc-web-client (1 module) and worker-client (1 module). All modules and libs are working fine, all, but the latter one. It is just not processed by ngcc. When I start the application I see the following:

Compiling @ngx-grpc/common : es2015 as esm2015

Compiling @ngx-grpc/core : es2015 as esm2015

Compiling @ngx-grpc/- removing all references to the `Worker` type () : es2015 as esm2015

Compiling @ngx-grpc/well-known-types : es2015 as esm2015

Compiling @ngx-grpc/worker : es2015 as esm2015

Compiling @ngx-grpc/worker-client : es2015 as esm2015

So, the ngcc reaches the library, but the directory __ivy_ngcc__ is not created in dist/worker-client, however for all other modules it is created. The outcome is that the latter library does not work.

What I tried:

removing all references to the Worker type from worker-client - did not help
checking angular config, including angular.json, tsconfigs and ng-packagr - did not help, it is totally equal to the working lib grpc-web-client
regenerated the lib from scratch - did not help
removed references to worker library from worker-client - did not help
moved code from worker-client to grpc-web-client lib. This made the code work, meaning that the grpc-web-client had no problems with ngcc; and I can use the code in the example and it works just fine. However, I cannot get more out of it; I still need the code in a separate package. This also means that code is valid and it can be compiled by ngcc, but for some reason when it's in its own package it does not.

What is also very weird - I would not be surprised if I had problems with worker library; it's built by Angular and used in Worker. And I have a feeling it can be connected to the issue.

I don't know what / where else to dig. The issue is driving me crazy. It seems unlogical to me and I cannot find the reason.

Please help me out.

🔬 Minimal Reproduction

Clone https://github.com/ngx-grpc/ngx-grpc
Switch to develop branch
npm ci
npm run build - builds the libs
npm run examples - produces the error after ngcc compiler

🔥 Exception or Error


    Error: dist/worker-client/lib/grpc-worker-client.module.d.ts:11:22 - error NG6002: Appears in the NgModule.imports of GrpcWorkerClientExampleModule, but could not be resolved to an NgModule class.
    
    This likely means that the dependency (@ngx-grpc/worker-client) which declares GrpcWorkerClientModule has not been processed correctly by ngcc.
    
    11 export declare class GrpcWorkerClientModule {

🌍 Your Environment


Angular CLI: 11.0.2
Node: 14.5.0
OS: darwin x64

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

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1100.2
@angular-devkit/build-angular   0.1100.2
@angular-devkit/core            11.0.2
@angular-devkit/schematics      11.0.2
@angular/cdk                    11.0.0
@angular/material               11.0.0
@schematics/angular             11.0.2
@schematics/update              0.1100.2
ng-packagr                      11.0.3
rxjs                            6.6.3
typescript                      4.0.5

Anything else relevant?

I'm not sure wheher the issue belongs to @angular/cli, please feel free to locate it properly in case it's necessary

The text was updated successfully, but these errors were encountered:

petebacondarwin · 2020-11-23T21:05:38Z

I've transferred this to the Framework repo as that is where ngcc is maintained. I'll take a look at this issue tomorrow.

smnbbrv · 2020-11-23T21:08:20Z

@petebacondarwin thank you very much! I would appreciate any help

petebacondarwin · 2020-11-24T09:01:23Z

@smnbbrv - I followed your instructions and I cannot reproduce the errors that you are seeing. (Note that I do not have docker-compose installed so I could not run npm run examples - instead I just ran npm run examples:basic).
I see this in the console:

Compiling @ngx-grpc/worker-client : es2015 as esm2015

And when I look at the dist/worker-client/lib/grpc-worker-client.module.d.ts file I see:

    static ɵmod: ɵngcc0.ɵɵNgModuleDefWithMeta<GrpcWorkerClientModule, never, never, never>;
    static ɵinj: ɵngcc0.ɵɵInjectorDef<GrpcWorkerClientModule>;

which indicates that ngcc has converted this to Ivy.

I wonder if you have some outdated files in node_modules? Perhaps try a complete clean of the repo?

petebacondarwin · 2020-11-24T09:03:05Z

I should also note that I see that package-lock.json is version 2, which I believe is the default for npm v7, yes?
I am running npm v6. Maybe v7 does some symlinking or something that is not compatible with ngcc?

smnbbrv · 2020-11-24T11:32:11Z

@petebacondarwin Thank you very much for the review.

It looks like the package.json was the issue. Clearing it up + node_modules fixed the issue. That weird.

Again, many thanks!

petebacondarwin · 2020-11-24T11:38:04Z

Great! I'm glad you are unblocked.

smnbbrv · 2020-11-24T12:11:58Z

Yep, sometimes the fix is so clear, and actually it's a shame I did not came to this on my own... It's always good to have a look from the outside :)

smnbbrv · 2020-11-25T20:13:00Z

OK, this is a bug and I found how to reproduce and work it around.

First of all, the updated reproduction steps are:

Clone https://github.com/ngx-grpc/ngx-grpc
Switch to develop branch
npm ci
npm run build - builds the libs
npm run examples - does not show any error
ls node_modules/.cli-ngcc - shows a directory that was created after npm run examples
npm run build - rebuild the libs
npm run examples - shows the error

Workaround:

rm -rf node_modules/.cli-ngcc && npm run build && npm run examples

@petebacondarwin is this intentional to have this file? Looks like it stores some metadata / state of the previous builds.

Is there a better way to deal with it / safe way to clear it up, let's say some command like ngcc clean or something similar?

petebacondarwin · 2020-11-25T20:18:28Z

This is something that Angular CLI adds. See https://github.com/angular/angular-cli/blob/51d0178d244ed3fb6feee280d02cf284ceed1b85/packages/ngtools/webpack/src/ngcc_processor.ts#L70-L76

Transferring to the CLI repository to continue the discussion...

clydin · 2020-11-26T02:18:59Z

It appears that the on-demand ngcc processing for that one library is partially failing. One of the .d.ts files is being changed (there is a backup file created) but no other changes are made. The reason deleting the lock file works around the issue is that it forces ngcc to perform a full run and bypasses the on-demand processing.
Further investigation will be needed to determine why that one library is not being processed properly.

alan-agius4 · 2021-01-08T10:21:43Z

Transferring to the FW repo as it appears to be a bug in NGCC path mapping logic.
See: #40352 for more information and a simpler reproduction.

//cc @klemenoslaj

petebacondarwin · 2021-01-08T16:44:30Z

I have found the source of the bug for #40352 - I'll check to see if this is the same problem.

Previously, if an entry-point started with the string of another package that is included in `paths` mappings, then the base path was incorrectly computed resulting in the wrong package path for the entry point. Now we not only check whether the target path "starts with" the base path but then also whether the target path is actually contained in the base path from a file-system directory point of view. Fixes angular#40352 Fixes angular#40357

petebacondarwin · 2021-01-09T18:34:25Z

Looks like #40376 solves this issue too. 🎉

Previously, if there were path-mapped entry-points, where one contaied the string of another - for example `worker-client` and `worker` - then the base paths were incorrectly computed resulting in the wrong package path for the longer entry-point. This was because, when searching for a matching base path, the strings were tested using `startsWith()`, whereas we should only match if the path was contained in a directory from a file-system point of view. Now we not only check whether the target path "starts with" the base path but then also whether the target path is actually contained in the base path using `fs.relative()`. Fixes angular#40352 Fixes angular#40357

…40376) Previously, if there were path-mapped entry-points, where one contaied the string of another - for example `worker-client` and `worker` - then the base paths were incorrectly computed resulting in the wrong package path for the longer entry-point. This was because, when searching for a matching base path, the strings were tested using `startsWith()`, whereas we should only match if the path was contained in a directory from a file-system point of view. Now we not only check whether the target path "starts with" the base path but then also whether the target path is actually contained in the base path using `fs.relative()`. Fixes #40352 Fixes #40357 PR Close #40376

angular-automatic-lock-bot · 2021-02-11T16:34:43Z

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

petebacondarwin transferred this issue from angular/angular-cli Nov 23, 2020

petebacondarwin self-assigned this Nov 23, 2020

smnbbrv closed this as completed Nov 24, 2020

smnbbrv reopened this Nov 25, 2020

petebacondarwin transferred this issue from angular/angular Nov 25, 2020

alan-agius4 unassigned petebacondarwin Dec 7, 2020

alan-agius4 transferred this issue from angular/angular-cli Jan 8, 2021

alan-agius4 transferred this issue from angular/ngcc-validation Jan 8, 2021

alan-agius4 added the comp: ngcc label Jan 8, 2021

ngbot bot added this to the needsTriage milestone Jan 8, 2021

alan-agius4 mentioned this issue Jan 8, 2021

NGCC failure with libraries of similar names #40352

Closed

petebacondarwin mentioned this issue Jan 9, 2021

fix(ngcc): compute the correct package paths for a target entry-points #40376

Closed

petebacondarwin added P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent state: has PR labels Jan 11, 2021

ngbot bot removed this from the needsTriage milestone Jan 11, 2021

ngbot bot modified the milestones: Backlog, needsTriage Jan 11, 2021

atscott closed this as completed in afd1166 Jan 11, 2021

angular-automatic-lock-bot bot locked and limited conversation to collaborators Feb 11, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Library is skipped by Ivy / ngcc compiler #40357

Library is skipped by Ivy / ngcc compiler #40357

smnbbrv commented Nov 23, 2020

petebacondarwin commented Nov 23, 2020

smnbbrv commented Nov 23, 2020

petebacondarwin commented Nov 24, 2020

petebacondarwin commented Nov 24, 2020

smnbbrv commented Nov 24, 2020

petebacondarwin commented Nov 24, 2020

smnbbrv commented Nov 24, 2020 •

edited

smnbbrv commented Nov 25, 2020

petebacondarwin commented Nov 25, 2020

clydin commented Nov 26, 2020

alan-agius4 commented Jan 8, 2021 •

edited

petebacondarwin commented Jan 8, 2021

petebacondarwin commented Jan 9, 2021

angular-automatic-lock-bot bot commented Feb 11, 2021

Library is skipped by Ivy / ngcc compiler #40357

Library is skipped by Ivy / ngcc compiler #40357

Comments

smnbbrv commented Nov 23, 2020

🐞 Bug report

Command (mark with an x)

Is this a regression?

Description

🔬 Minimal Reproduction

🔥 Exception or Error

🌍 Your Environment

petebacondarwin commented Nov 23, 2020

smnbbrv commented Nov 23, 2020

petebacondarwin commented Nov 24, 2020

petebacondarwin commented Nov 24, 2020

smnbbrv commented Nov 24, 2020

petebacondarwin commented Nov 24, 2020

smnbbrv commented Nov 24, 2020 • edited

smnbbrv commented Nov 25, 2020

petebacondarwin commented Nov 25, 2020

clydin commented Nov 26, 2020

alan-agius4 commented Jan 8, 2021 • edited

petebacondarwin commented Jan 8, 2021

petebacondarwin commented Jan 9, 2021

angular-automatic-lock-bot bot commented Feb 11, 2021

Command (mark with an `x`)

smnbbrv commented Nov 24, 2020 •

edited

alan-agius4 commented Jan 8, 2021 •

edited