Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NGCC failure with libraries of similar names #40352

Closed
klemenoslaj opened this issue Jan 8, 2021 · 4 comments
Closed

NGCC failure with libraries of similar names #40352

klemenoslaj opened this issue Jan 8, 2021 · 4 comments
Milestone
needsTriage

Comments

@klemenoslaj
Copy link
Contributor

klemenoslaj commented Jan 8, 2021 •
edited

🐞 bug report

Affected Package

@angular/compiler-cli - ngcc

Is this a regression?

Pretty sure it worked in older versions.

Description

If two libraries have the same name, but the second one has the additional suffix, the ngcc will fail.

Example

  1. library: demo-lib
  2. library: demo-lib-shell

demo-lib imports demo-lib-shell module and demo-lib is imported by the application.

Additional observation

To my surprise, the failure only happens if demo-lib-shell library is configured after demo-lib in tsconfig.json paths, as in:

{
  "compilerOptions": {
    "paths": {
      "demo-lib": [
        "dist/demo-lib/demo-lib",
        "dist/demo-lib"
      ],
      "demo-lib-shell": [
        "dist/demo-lib-shell/demo-lib-shell",
        "dist/demo-lib-shell"
      ]
    }
  }
}

If this configuration is reversed, ngcc will not fail.

🔬 Minimal Reproduction

Clone: https://github.com/klemenoslaj/ngcc-failure--library-name
Install dependencies: yarn
Reproduce the issue: yarn reproduce OR yarn reproduce:docker

NOTE: There is a chance that on the first try right after dependency installation this will succeed, but will fail when yarn reproduce is executed again. This probably has something to do with the fact that the rest of dependencies from node_modules are processed as well first time, but I could be wrong.

NOTE 2: This seems to fail consistantly even on the first try in Docker. To that end I have added a docker file and updated the reproduction above accordingly.

🔥 Exception or Error


⠋ Generating browser application bundles...
Compiling demo-lib-shell : es2015 as esm2015

Compiling demo-lib : es2015 as esm2015
✔ Browser application bundle generation complete.

Error: Failed to compile entry-point demo-lib (es2015 as esm2015) due to compilation errors:
dist/demo-lib-shell/lib/demo-lib-shell.module.d.ts:1:22 - error NG6002: Appears in the NgModule.imports of DemoLibModule, but could not be resolved to an NgModule class.

This likely means that the dependency (demo-lib-shell) which declares DemoLibShellModule has not been processed correctly by ngcc.

1 export declare class DemoLibShellModule {
                       ~~~~~~~~~~~~~~~~~~



error Command failed with exit code 1.

🌍 Your Environment

Angular Version:


Angular CLI: 11.0.6
Node: 14.15.0
OS: darwin x64

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

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1100.6
@angular-devkit/build-angular   0.1100.6
@angular-devkit/core            11.0.6
@angular-devkit/schematics      11.0.6
@angular/cli                    11.0.6
@schematics/angular             11.0.6
@schematics/update              0.1100.6
ng-packagr                      11.0.3
rxjs                            6.6.3
typescript                      4.0.5
@klemenoslaj klemenoslaj changed the title NGCC failure NGCC failure with libraries of similar names Jan 8, 2021
@alan-agius4
Copy link
Contributor

alan-agius4 commented Jan 8, 2021 •
edited

Hi,

I had a look at this and what is happening is that during the first run. NGCC will run on all node_modules. While during the 2nd run it will only run on your local libraries because the node packages are not modified and a lock file exists in node_modules/.cli-ngcc.

What I noticed is that when running the NGCC during module resolution (2nd run) it breaks the library as this is not processed correctly. (Notice: dist/demo-lib/demo-lib-shell).

Screenshot 2021-01-08 at 11 18 23

This issue seems to be a duplicate of https://github.com/angular/angular-cli/issues/19484

@alan-agius4
Copy link
Contributor

Duplicate of #40357

@alan-agius4 alan-agius4 marked this as a duplicate of #40357 Jan 8, 2021
@ngbot ngbot bot added this to the needsTriage milestone Jan 8, 2021
@alan-agius4 alan-agius4 mentioned this issue Jan 8, 2021
Closed
15 tasks
@petebacondarwin
Copy link
Member

I have found the source of the bug - working on a fix.

petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 9, 2021
@petebacondarwin
fix(ngcc): compute the correct package paths for a target entry-points
09c9c56 
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 petebacondarwin mentioned this issue Jan 9, 2021
Closed
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 10, 2021
@petebacondarwin
fix(ngcc): compute the correct package paths for target entry-points
7e7769a 
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
atscott pushed a commit that referenced this issue Jan 11, 2021
@petebacondarwin @atscott
fix(ngcc): compute the correct package paths for target entry-points (#…
afd1166 
…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
atscott pushed a commit that referenced this issue Jan 11, 2021
@petebacondarwin @atscott
fix(ngcc): compute the correct package paths for target entry-points (#…
584b78a 
…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
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Feb 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
needsTriage
Development

Successfully merging a pull request may close this issue.

fix(ngcc): compute the correct package paths for a target entry-points petebacondarwin/angular
3 participants
@petebacondarwin @klemenoslaj @alan-agius4