fix(angular): fix Coveo headless error on application run

[y-lakhdar]

https://coveord.atlassian.net/browse/CDX-280

Proposed changes

I updated the angular tsconfig.json file to include the allowSyntheticDefaultImports flag. Otherwise the npm start command leads to an error (see image).

Note:

All other templates (React and Vue) have the allowSyntheticDefaultImports flag in their tsconfig.json.

Testing

This is already covered by current E2E tests.

---

CDX-280

[github-actions]

Pull Request Report

PR Title

✅ Title follows the conventional commit spec.

[louis-bompart]

The way we modify the tsconfig.json seems odd to me.
Can't we as a schematic author act upon the tsconfig in a less roundabout way?
I was wondering especially after reading this page from Angular documentation:

Your library needs a custom Typescript configuration file with instructions on how to compile your schematics into your distributed library.

https://angular.io/guide/schematics-for-libraries#building-your-schematics

[y-lakhdar]

The way we modify the tsconfig.json seems odd to me.
Can't we as a schematic author act upon the tsconfig in a less roundabout way?
I was wondering especially after reading this page from Angular documentation:

Your library needs a custom Typescript configuration file with instructions on how to compile your schematics into your distributed library.

https://angular.io/guide/schematics-for-libraries#building-your-schematics

mmh.. I think that custom tsconfig file is only used in the schematic compilation rather than being applied to the generated project.
Another option would be to have our own tsconfig file within the template. However, it means completely overriding the existing one.

[olamothe]

Another approach might be to just skipLibCheck=true in ts config ?

If that works, I'd prefer this one. Otherwise these kind of problem will keep popping up from time to time.

[louis-bompart]

The way we modify the tsconfig.json seems odd to me.
Can't we as a schematic author act upon the tsconfig in a less roundabout way?
I was wondering especially after reading this page from Angular documentation:

Your library needs a custom Typescript configuration file with instructions on how to compile your schematics into your distributed library.

https://angular.io/guide/schematics-for-libraries#building-your-schematics

mmh.. I think that custom tsconfig file is only used in the schematic compilation rather than being applied to the generated project.
Another option would be to have our own tsconfig file within the template. However, it means completely overriding the existing one.

Do you know if we can detect if we're generating or adding the project?
What I would do iff we're detecting that we're adding is not modify the tsconfig but indicate that our template either requires:

• skipLibCheck as @olamothe proposed
• allowSyntheticDefaultImports, as currently proposed.

I think we should also try to see what would be the impact of both on the customer project, what does he win or lose.
We should also check what are the good practices of the Angular schematics in general.

Tho, if the issue is pressing, we can also proceed with a fix-it twice logic: Fix it with the proposed changes here (it works fine really), and investigate afterwards to see what's the 'best' fix.

(Personnaly, I locked the headless version to 0.10.0 for my test)

[y-lakhdar]

The way we modify the tsconfig.json seems odd to me.
Can't we as a schematic author act upon the tsconfig in a less roundabout way?
I was wondering especially after reading this page from Angular documentation:

Your library needs a custom Typescript configuration file with instructions on how to compile your schematics into your distributed library.

https://angular.io/guide/schematics-for-libraries#building-your-schematics

mmh.. I think that custom tsconfig file is only used in the schematic compilation rather than being applied to the generated project.
Another option would be to have our own tsconfig file within the template. However, it means completely overriding the existing one.

Do you know if we can detect if we're generating or adding the project?
What I would do iff we're detecting that we're adding is not modify the tsconfig but indicate that our template either requires:

• skipLibCheck as @olamothe proposed
• allowSyntheticDefaultImports, as currently proposed.

I think we should also try to see what would be the impact of both on the customer project, what does he win or lose.
We should also check what are the good practices of the Angular schematics in general.

Tho, if the issue is pressing, we can also proceed with a fix-it twice logic: Fix it with the proposed changes here (it works fine really), and investigate afterwards to see what's the 'best' fix.

(Personnaly, I locked the headless version to 0.10.0 for my test)

Yes, we can detect if we are adding or updating a file. However in this case, I'm pretty sure we will always be updating the file.
Angular schematic SDK offers plenty of util functions to dynamically insert code fragment into the project tree, but nothing specific to the tsconfig file.
We can go with a stronger approach and use a public method such as insertAfterLastOccurrence and prevent a hackish JSON parse.

@olamothe, skipLibCheck=true works