fix(@angular-devkit/build-angular): handle basename collisions

[hybrist]

Generates unique names for each test entry point and also creates a nice & consistent name for the main ("init test bed") chunk. All specs are now spec-*.js files.

Fixes #28756

P.S.: Current based on #28795, will rebase post-merge.

[hybrist]

Adding @dgp1130 as another reviewer in case he has thoughts on the changes to the entryPoints option (based on Chat discussion with @clydin).

[dgp1130]

The use of a Map to explicitly define output entry points seems generally reasonable. But I'm wondering if we should allow Set at all? I think this was already an issue for the Jest and WTR builders which I hadn't gotten to fixing yet and it makes me think we should never use the Set case as its implemented today or we'll potentially run into the same bug. I'm thinking we should either:

1. Remove Set from the parameter type altogether and require a Map. All callers need to manually construct this Map.
2. Update normalizeEntryPoints to find and deduplicate basenames in the set (foo.spec.js becomes foo.spec-2.js) so the caller doesn't need to worry about this.

I'd probably lean towards 2., given that Jest and WTR are likely to duplicate the work done in the Karma builder, and if we go with 2. they likely wouldn't need to worry about this given that none of the test runners really care about the output file name too much.

[hybrist]

A potential issue with 2 is that the test runners (or, at least Karma) need to be able to find the entrypoints afterwards to load them. Which makes me lean towards refactoring the Jest/WTR builders to use the Map as well.

Either way, happy to do a potential follow-up if necessary to ensure that we only have one or the other at the end of this. Agreed that we should pick one data structure, not both.

[dgp1130]

A potential issue with 2 is that the test runners (or, at least Karma) need to be able to find the entrypoints afterwards to load them. Which makes me lean towards refactoring the Jest/WTR builders to use the Map as well.

I did have a similar thought, but I feel it's manageable if we either maintain the relevant extension (.spec.js), though that might be a little tricky without codifying that particular extension into application builder, or we could potentially dump these into a subdirectory like dist/entry-points/... where the exact file name doesn't matter because all the entry points are there instead of dist/chunk-*.js. Not sure exactly which of these would be easier, but it's a potential option.

I'm fine to tackle that as a follow up, it would definitely be great to have a common solution for all three test runners.

[hybrist]

I'm fine to tackle that as a follow up, it would definitely be great to have a common solution for all three test runners.

FWIW, that is a general theme for the application builder support for Karma. I've been lifting code (e.g. writeTestOutputs) from the other runners and it would likely be nice to refactor to make sure we don't have unnecessary duplication.

[hybrist]

The changes were merged into the following branches: main, 19.0.x

[angular-automatic-lock-bot]

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