bug(migrations): migration-v13 unresolved TS project for non-buildable / test target without tsconfig path projects

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

When running the migration (migration-v13), the following is printed to the console: Could not find TypeScript project for project: project-name

This appears to be the result of the logic that is being used to find the TSConfig file for the project in the angular.json. It is looking for test targets that use the @angular-devkit/build-angular:karma builder, ignoring that there might be other builders being used for the test target that contain a path to the tsconfig file.

After more investigation, I can narrow this down a bit more. it’s related to the getTargetTsconfigPath function.

Some library projects may not have a build target by default, and their test target may be using jest which does not contain a tsconfig property.

This definitely makes it more difficult to determine a tsconfig path. Especially as there may not be a standard convention for the lib’s tsconfig file name.

Reproduction

Steps to reproduce: 1. Change the test target’s builder of any project using Angular Material 2. Try run the migration

1. Have a project in angular.json that does not have a build target, or a tsconfig property in the test target

Expected Behavior

It should run the migration with no errors / warnings.

Actual Behavior

It does not find the tsconfig for the project therefore the migration logs warnings.

Environment

• Angular: 13.0.0
• CDK/Material: 13.0.0
• Operating System (e.g. Windows, macOS, Ubuntu): macOS

[devversion]

yeah, I think we need some more thoughts on this. I think a first step is to stop migrating other projects/targets (as mentioned before), and then we should look for ways that allow specification of a tsconfig. I like the idea of a migrate command, but that would be something to check with the CLI team. For now I could imagine us providing a ng generate schematic entry-point. e.g. ng generate @angular/cdk:migrations-v12 --tsConfig=<..> or something around that.

[Coly010]

@devversion yeah exactly, the real issue here is that the TS Program will have similar future issues during migration 🙂