Additional TS schematics schema API

[kroeder]

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Description

I already commented on this in #18578 (comment) but thought this is worth a separate issue since the other issue is not directly related to my proposal.

The current schema.json approach where you can define different inputs to your schematic is fine for a lot of schematics. However, there are a few that would greatly benefit from a more dynamic approach! There are other issues that requested a separate type for the JSON schema but I think this would over-complicate the current easy approach.

My proposal is to offer a TypeScript API as a target for a schematic schema.

Example collection.json

{
    "schematic-with-typescript-schema": {
        "description": "...",
        "factory": "...",
        "schema": "./some-schematic/schema#typescriptSchema"
    }
}

Example TS schema

/**
 * User code
 */
interface MyInput {
    name: string;
    path: string;
    needsFooter: boolean;
    footerColor?: FooterColor;
}

type FooterColor = 'blue' | 'green' | 'red';

export function TSExampleSchema() {
    return schematicsSchema<MyInput>({
        name: () => createInput({
            type: InputTypes.STRING,
            xPrompt: "Name of your component"
        }),
        path: () => executionPath(),
        needsFooter: () => createInput({
            type: InputTypes.BOOLEAN,
            xPrompt: "Do you need a footer?"
        }),
        footerColor: (prevValues) => prevValues.needsFooter 
            ? createInput({
                type: InputTypes.ENUM,
                enum: [
                    "blue",
                    "green",
                    "red"
                ],
                xPrompt: "Footer color"
            })
          : noop()
    })
}

This is more-or-less pseudo-code to give you an idea of what I want to achieve: an API that is more flexible but one that should not replace the simple JSON approach.

One example usage could be something like a table schematic that already knows the target data model by pre-fetching possible selections from a e.g. GraphQL Introspection before offering a list of answers

ng generate my-package:table
> Based on which model?
   [ ] Users
   [ ] Articles
   [ ] Products

Describe the solution you'd like

A TS API to offer more advanced schematics

Describe alternatives you've considered

Extending the current JSON API. However, it is good as it is right now and most likely could not offer an async API without being over-complicated

[alan-agius4]

This is somewhat also related to #16705.

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.