Repository navigation
Conversation
…ration Karma migration The Karma to Vitest migration moves build-only test options such as `styles` into a `testing` build configuration and points the test target at it. For each test configuration it created a separate `testing-<name>` build configuration containing only that configuration's own options. Because a test configuration's `buildTarget` replaces the base one, running `ng test --configuration <name>` lost the options moved from the base test options. Merge the base options into each per-configuration build configuration, with the configuration's own values taking precedence.
There was a problem hiding this comment.
Code Review
This pull request updates the Karma to Vitest migration schematic to correctly handle inheritance of base test options in per-configuration build settings. It ensures that custom build options are properly merged, preventing potential configuration loss. The review feedback highlights a potential issue with spreading undefined base options and provides a safer implementation using a guard clause.
| const mergedOptions = configKey | ||
| ? { ...customBuildOptions[''], ...configOptions } | ||
| : configOptions; |
There was a problem hiding this comment.
If customBuildOptions[''] is undefined (which can happen if the test target has no base options defined), spreading it directly in { ...customBuildOptions[''], ...configOptions } might lead to potential issues or TypeScript compilation errors depending on the compiler settings (such as noUncheckedIndexedAccess). Adding a guard to ensure customBuildOptions[''] is defined before spreading is safer and more robust.
| const mergedOptions = configKey | |
| ? { ...customBuildOptions[''], ...configOptions } | |
| : configOptions; | |
| const mergedOptions = configKey && customBuildOptions[''] | |
| ? { ...customBuildOptions[''], ...configOptions } | |
| : configOptions; |
| // A test configuration inherits the base test options, so its build configuration must | ||
| // include the build options moved from them, with the configuration's own values on top. | ||
| const mergedOptions = configKey | ||
| ? { ...customBuildOptions[''], ...configOptions } |
There was a problem hiding this comment.
styles case is fixed but aot comes back - processTestTargetOptions seeds every config entry with { aot: false, optimization: false, extractLicenses: false }, so seeded aot: false of ci wins over explicit aot: true from base here
test options { styles, aot: true } + ci: { watch: false } gives testing with aot: true and testing-ci with aot: false, so ng test runs AOT and ng test -c ci runs JIT. same for optimization and extractLicenses
new spec doesnt set aot so it passes either way
seeding Karma defaults only for base entry looks enough, configs then get them through this merge (checked on 22.3.0-next.2 with it patched in):
customBuildOptions[configKey] = configKey
? {}
: {
aot: false,
optimization: false,
extractLicenses: false,
};
The Karma to Vitest migration moves build-only test options such as
stylesinto atestingbuild configuration and points the test target at it. For each test configuration it created a separatetesting-<name>build configuration containing only that configuration's own options. Because a test configuration'sbuildTargetreplaces the base one, runningng test --configuration <name>lost the options moved from the base test options.Merge the base options into each per-configuration build configuration, with the configuration's own values taking precedence.