fix(@angular/cli): handle oneOf when converting schema to yargs options

[terencehonles]

PR Checklist

Please check to confirm your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

Options such as --allowed-hosts are defined as oneOf([array<string>, boolean]) but the array option is not chosen, even though it is first, because the JSONSchema conversion only supports an array at the root of the option schema.

Issue Number: N/A

What is the new behavior?

This change fixes JSONSchemas where oneOf is placed at the root of the option schema rather than in an array's items. This allows an array to be passed via the command-line, but additional types to be represented via configuration.

Does this PR introduce a breaking change?

• Yes
• No

This will affect any commands for each of the options that use oneOf at the root of their schemas. This change does not change the precedence of schema definition, so if there are any changes and they are not wanted then it is just uncovering a bug where the preferred type should have been ordered first.

Other information

[alan-agius4]

This is a breaking change --no-allowed-hosts will become non-functional.

[terencehonles]

I forgot --no-allowed-hosts would be one of the accepted forms, but I think it's probably unlikely that allowed hosts are configured but you want to turn that off via the command line. You may be able to use --allowed-hosts "" to fake the same thing, as "" shouldn't match anything.

I looked into how yargs does its parsing and it almost works (it doesn't actually are about the option definition). Using --no-oneOfAtRoot I expected it to return false, but it returns [false] which would fail the validation.

[terencehonles]

The change I pushed should handle --no-allowed-hosts as yargs will try to guess you want a boolean in this case, and since the type is not declared as an array, it will return a single boolean value instead of the [false] I was seeing before. It's possible the recursive function I added should just be a default to string, but this will try to find things like an array of numbers (which I just added a test for)

[alan-agius4]

See comments

[alan-agius4]

Consider the below, which IMO it's slightly easier to read.

Suggested change

	type SupportedPrimitiveType = Parameters<typeof SUPPORTED_PRIMITIVE_TYPES.add>[0];
	const types = ['boolean', 'number', 'string'] as const;
	const SUPPORTED_PRIMITIVE_TYPES: ReadonlySet<string> = new Set(types);
	type SupportedPrimitiveType = (typeof types)[number];

[alan-agius4]

Remove the casting, this is not needed if you change the set type.

Suggested change

	return SUPPORTED_PRIMITIVE_TYPES.has(value as any);
	return SUPPORTED_PRIMITIVE_TYPES.has(value);

[alan-agius4]

This isn't right as it cause the array type to be replaced by a primitive and forces yargs to parse it as a non array. Example --flag foo bar will now become invalid.