History

Pete Bacon Darwin 995cd15a69 fix(ngcc): correctly identify the package path of secondary entry-points (#36249 )

Previously we only searched for package paths below the set of `basePaths`
that were computed from the `basePath` provided to ngcc and the set of
`pathMappings`.

In some scenarios, such as hoisted packages, the entry-point is not within
any of the `basePaths` identified above. For example:

```
project
  packages
    app
      node_modules
        app-lib (depends on lib1)
  node_modules
    lib1 (depends on lib2)
      node_modules
        lib2 (depends on lib3/entry-point)
    lib3
      entry-point
```

When CLI is compiling `app-lib` ngcc will be given
`project/packages/app/node_modules` as the `basePath.

If ngcc is asked to target `lib2`, the `targetPath` will be
`project/node_modules/lib1/node_modules/lib2`.

Since `lib2` depends upon `lib3/entry-point`, ngcc will need to compute
the package path for `project/node_modules/lib3/entry-point`.

Since `project/node_modules/lib3/entry-point` is not contained in the `basePath`
`project/packages/app/node_modules`, ngcc failed to compute the `packagePath`
correctly, instead assuming that it was the same as the entry-point path.

Now we also consider the nearest `node_modules` folder to the entry-point
path as an additional `basePath`. If one is found then we use the first
directory directly below that `node_modules` directory as the package path.

In the case of our example this extra `basePath` would be `project/node_modules`
which allows us to compute the `packagePath` of `project/node_modules/lib3`.

Fixes #35747

PR Close #36249

2020-03-27 11:17:45 -07:00

src

fix(ngcc): correctly identify the package path of secondary entry-points (#36249 )

2020-03-27 11:17:45 -07:00

test

fix(ngcc): correctly identify the package path of secondary entry-points (#36249 )

2020-03-27 11:17:45 -07:00

BUILD.bazel

fix(ngcc): use path-mappings from tsconfig in dependency resolution (#36180 )

2020-03-24 10:16:12 -07:00

index.ts

refactor(ngcc): expose logging level on the logger (#35861 )

2020-03-05 18:17:15 -05:00

main-ivy-ngcc.ts

fix(ngcc): rename the executable from ivy-ngcc to ngcc (#33140 )

2019-10-14 16:29:14 +00:00

main-ngcc.ts

fix(ngcc): use path-mappings from tsconfig in dependency resolution (#36180 )

2020-03-24 10:16:12 -07:00

README.md

refactor(ivy): move ngcc into a higher level folder (#29092 )

2019-03-20 14:45:54 -04:00

README.md

Angular Compatibility Compiler (ngcc)

This compiler will convert node_modules compiled with ngc, into node_modules which appear to have been compiled with ngtsc.

This conversion will allow such "legacy" packages to be used by the Ivy rendering engine.

Building

The project is built using Bazel:

yarn bazel build //packages/compiler-cli/ngcc

Unit Testing

The unit tests are built and run using Bazel:

yarn bazel test //packages/compiler-cli/ngcc/test

Integration Testing

There are tests that check the behavior of the overall executable:

yarn bazel test //packages/compiler-cli/ngcc/test:integration