fix(@angular/cli): skip CLI version check for migrate-only updates

[maruthang]

Summary

• When running ng update @angular/cli --name=use-application-builder, the CLI fetched and installed the latest version (e.g., v20) as a temporary CLI, even though migrate-only mode operates on the currently installed package version
• This caused incompatible packages to be installed (e.g., @angular/build@20 on an Angular 18/19 project)
• The fix adds !options.migrateOnly to the CLI version check condition, skipping it when using --name or --migrate-only since migrations run against the installed version

Closes #30696

Test plan

• Run ng update @angular/cli --name=use-application-builder on an Angular 19 project — should use the installed CLI, not fetch latest
• Run ng update @angular/cli (without --name) — should still check for newer CLI version as before
• Run ng update @angular/cli --migrate-only — should skip CLI version check

[gemini-code-assist]

Code Review

This pull request introduces granular sourcemap configuration for the Vite dev server, specifically adding support for style sourcemaps, and updates the ng update command to skip version checks during migrate-only operations. Feedback indicates that the current implementation might inadvertently disable CSS sourcemaps by default, which would be a regression in developer experience. Additionally, it was noted that the JavaScriptTransformer for third-party dependencies should use the thirdPartySourcemaps setting instead of scriptsSourcemaps to ensure logical consistency and maintain existing behavior for prebundled files.

[gemini-code-assist]

Defaulting sourceMap to false here (via ?? false) causes stylesSourcemaps to be false by default. Since stylesSourcemaps is now used to control devSourcemap in the Vite server (which was previously hardcoded to true), this change disables CSS sourcemaps by default in ng serve. To maintain the existing developer experience where CSS sourcemaps are enabled by default even if not explicitly configured in the build options, consider using a default that preserves this behavior for styles.

Suggested change

	const {
	vendor: thirdPartySourcemaps,
	scripts: scriptsSourcemaps,
	styles: stylesSourcemaps,
	} = normalizeSourceMaps(browserOptions.sourceMap ?? false);
	const {
	vendor: thirdPartySourcemaps,
	scripts: scriptsSourcemaps,
	styles: stylesSourcemaps,
	} = normalizeSourceMaps(browserOptions.sourceMap ?? { styles: true });

References

1. When refactoring code that handles configuration properties, ensure that any implicit type validation previously performed is still maintained, especially if the configuration is guaranteed to be type-safe by an upstream process.

[gemini-code-assist]

The JavaScriptTransformer created here is specifically intended for prebundling third-party dependencies (as noted in the comment on line 186). Using scriptsSourcemaps (which corresponds to the application's script sourcemap setting) as the primary sourcemap toggle is logically incorrect for this purpose; it should use thirdPartySourcemaps to correctly respect the configuration for dependencies. Additionally, changing this from a hardcoded true to a variable that defaults to false (when sourceMap is undefined) disables sourcemaps for prebundled files by default, which is a regression in the development experience.

Suggested change

	{ sourcemap: scriptsSourcemaps, jit: true, thirdPartySourcemaps },
	{ sourcemap: thirdPartySourcemaps, jit: true, thirdPartySourcemaps },

References

1. When refactoring code that handles configuration properties, ensure that any implicit type validation previously performed is still maintained, especially if the configuration is guaranteed to be type-safe by an upstream process.