Authoring schematicslink
\nYou can create your own schematics to operate on Angular projects.\nLibrary developers typically package schematics with their libraries in order to integrate them with the Angular CLI.\nYou can also create stand-alone schematics to manipulate the files and constructs in Angular applications as a way of customizing them for your development environment and making them conform to your standards and constraints.\nSchematics can be chained, running other schematics to perform complex operations.
\nManipulating the code in an application has the potential to be both very powerful and correspondingly dangerous.\nFor example, creating a file that already exists would be an error, and if it was applied immediately, it would discard all the other changes applied so far.\nThe Angular Schematics tooling guards against side effects and errors by creating a virtual file system.\nA schematic describes a pipeline of transformations that can be applied to the virtual file system.\nWhen a schematic runs, the transformations are recorded in memory, and only applied in the real file system once they're confirmed to be valid.
\nSchematics conceptslink
\nThe public API for schematics defines classes that represent the basic concepts.
\n- \n
- \n
The virtual file system is represented by a
\nTree. TheTreedata structure contains a base (a set of files that already exists) and a staging area (a list of changes to be applied to the base).\nWhen making modifications, you don't actually change the base, but add those modifications to the staging area. \n - \n
A
\nRuleobject defines a function that takes aTree, applies transformations, and returns a newTree. The main file for a schematic,index.ts, defines a set of rules that implement the schematic's logic. \n - \n
A transformation is represented by an
\nAction. There are four action types:Create,Rename,Overwrite, andDelete. \n - \n
Each schematic runs in a context, represented by a
\nSchematicContextobject. \n
The context object passed into a rule provides access to utility functions and metadata that the schematic may need to work with, including a logging API to help with debugging.\nThe context also defines a merge strategy that determines how changes are merged from the staged tree into the base tree. A change can be accepted or ignored, or throw an exception.
\nDefining rules and actionslink
\nWhen you create a new blank schematic with the Schematics CLI, the generated entry function is a rule factory.\nA RuleFactory object defines a higher-order function that creates a Rule.
Your rules can make changes to your projects by calling external tools and implementing logic.\nYou need a rule, for example, to define how a template in the schematic is to be merged into the hosting project.
\nRules can make use of utilities provided with the @schematics/angular package. Look for helper functions for working with modules, dependencies, TypeScript, AST, JSON, Angular CLI workspaces and projects, and more.
Defining input options with a schema and interfaceslink
\nRules can collect option values from the caller and inject them into templates.\nThe options available to your rules, with their allowed values and defaults, are defined in the schematic's JSON schema file, <schematic>/schema.json.\nYou can define variable or enumerated data types for the schema using TypeScript interfaces.
The schema defines the types and default values of variables used in the schematic.\nFor example, the hypothetical \"Hello World\" schematic might have the following schema.
\nYou can see examples of schema files for the Angular CLI command schematics in @schematics/angular.
Schematic promptslink
\nSchematic prompts introduce user interaction into schematic execution.\nYou can configure schematic options to display a customizable question to the user.\nThe prompts are displayed before the execution of the schematic, which then uses the response as the value for the option.\nThis allows users to direct the operation of the schematic without requiring in-depth knowledge of the full spectrum of available options.
\nThe \"Hello World\" schematic might, for example, ask the user for their name, and display that name in place of the default name \"world\". To define such a prompt, add an x-prompt property to the schema for the name variable.
Similarly, you can add a prompt to allow the user to decide whether the schematic will use color when executing its hello action. The schema with both prompts would be as follows.
\nPrompt short-form syntaxlink
\nThese examples use a shorthand form of the prompt syntax, supplying only the text of the question.\nIn most cases, this is all that is required.\nNotice however, that the two prompts expect different types of input.\nWhen using the shorthand form, the most appropriate type is automatically selected based on the property's schema.\nIn the example, the name prompt uses the input type because it it is a string property.\nThe useColor prompt uses a confirmation type because it is a Boolean property.\nIn this case, \"yes\" corresponds to true and \"no\" corresponds to false.
There are three supported input types.
\n| Input type | \nDescription | \n
|---|---|
| confirmation | \nA yes or no question; ideal for Boolean options. | \n
| input | \nTextual input; ideal for string or number options. | \n
| list | \nA predefined set of allowed values. | \n
In the short form, the type is inferred from the property's type and constraints.
\n| Property Schema | \nPrompt Type | \n
|---|---|
| \"type\": \"boolean\" | \nconfirmation (\"yes\"=true, \"no\"=false) | \n
| \"type\": \"string\" | \ninput | \n
| \"type\": \"number\" | \ninput (only valid numbers accepted) | \n
| \"type\": \"integer\" | \ninput (only valid numbers accepted) | \n
| \"enum\": [...] | \nlist \t(enum members become list selections) | \n
In the following example, the property takes an enumerated value, so the schematic automatically chooses the list type, and creates a menu from the possible values.
\nThe prompt runtime automatically validates the provided response against the constraints provided in the JSON schema.\nIf the value is not acceptable, the user is prompted for a new value.\nThis ensures that any values passed to the schematic meet the expectations of the schematic's implementation, so that you do not need to add additional checks within the schematic's code.
\nPrompt long-form syntaxlink
\nThe x-prompt field syntax supports a long form for cases where you require additional customization and control over the prompt.\nIn this form, the x-prompt field value is a JSON object with subfields that customize the behavior of the prompt.
| Field | \nData Value | \n
|---|---|
| type | \nconfirmation, input, or list (selected automatically in short form) | \n
| message | \nstring (required) | \n
| items | \nstring and/or label/value object pair (only valid with type list) | \n
The following example of the long form is from the JSON schema for the schematic that the CLI uses to generate applications.\nIt defines the prompt that allows users to choose which style preprocessor they want to use for the application being created.\nBy using the long form, the schematic can provide more explicit formatting of the menu choices.
\nx-prompt schemalink
\nThe JSON schema that defines a schematic's options supports extensions to allow the declarative definition of prompts and their respective behavior.\nNo additional logic or changes are required to the code of a schematic to support the prompts.\nThe following JSON schema is a complete description of the long-form syntax for the x-prompt field.
Schematics CLIlink
\nSchematics come with their own command-line tool.\nUsing Node 6.9 or above, install the Schematics command line tool globally:
\nThis installs the schematics executable, which you can use to create a new schematics collection in its own project folder, add a new schematic to an existing collection, or extend an existing schematic.
In the following sections, we will create a new schematics collection using the CLI in order to introduce the files and file structure, and some of the basic concepts.
\nThe most common use of schematics, however, is to integrate an Angular library with the Angular CLI.\nYou can do this by creating the schematic files directly within the library project in an Angular workspace, without using the Schematics CLI.\nSee Schematics for Libraries.
\nCreating a schematics collectionlink
\nThe following command creates a new schematic named hello-world in a new project folder of the same name.
The blank schematic is provided by the Schematics CLI. The command creates a new project folder (the root folder for the collection) and an initial named schematic in the collection.
Go to the collection folder, install your npm dependencies, and open your new collection in your favorite editor to see the generated files. For example, if you are using VSCode:
\nThe initial schematic gets the same name as the project folder, and is generated in src/hello-world.\nYou can add related schematics to this collection, and modify the generated skeleton code to define your schematic's functionality.\nEach schematic name must be unique within the collection.
Running a schematiclink
\nUse the schematics command to run a named schematic.\nProvide the path to the project folder, the schematic name, and any mandatory options, in the following format.
The path can be absolute or relative to the current working directory where the command is executed.\nFor example, to run the schematic we just generated (which has no required options), use the following command.
\nAdding a schematic to a collectionlink
\nTo add a schematic to an existing collection, use the same command you use to start a new schematics project, but run the command inside the project folder.
\nThe command generates the new named schematic inside your collection, with a main index.ts file and its associated test spec.\nIt also adds the name, description, and factory function for the new schematic to the collection's schema in the collection.json file.
Collection contentslink
\nThe top level of the root project folder for a collection contains configuration files, a node_modules folder, and a src/ folder.\nThe src/ folder contains subfolders for named schematics in the collection, and a schema, collection.json, which describes the collected schematics.\nEach schematic is created with a name, description, and factory function.
- \n
- The
$schemaproperty specifies the schema that the CLI uses for validation. \n - The
schematicsproperty lists named schematics that belong to this collection.\nEach schematic has a plain-text description, and points to the generated entry function in the main file. \n - The
factoryproperty points to the generated entry function. In this example, you invoke thehello-worldschematic by calling thehelloWorld()factory function. \n - The optional
schemaproperty points to a JSON schema file that defines the command-line options available to the schematic. \n - The optional
aliasesarray specifies one or more strings that can be used to invoke the schematic.\nFor example, the schematic for the Angular CLI “generate” command has an alias “g”, allowing you to use the commandng g. \n
Named schematicslink
\nWhen you use the Schematics CLI to create a blank schematics project, the new blank schematic is the first member of the collection, and has the same name as the collection.\nWhen you add a new named schematic to this collection, it is automatically added to the collection.json schema.
In addition to the name and description, each schematic has a factory property that identifies the schematic’s entry point.\nIn the example, you invoke the schematic's defined functionality by calling the helloWorld() function in the main file, hello-world/index.ts.
![\"overview\"](\"generated/images/guide/schematics/collection-files.gif\")
\nEach named schematic in the collection has the following main parts.
\n| \n | \n |
|---|---|
index.ts | \nCode that defines the transformation logic for a named schematic. | \n
schema.json | \nSchematic variable definition. | \n
schema.d.ts | \nSchematic variables. | \n
files/ | \nOptional component/template files to replicate. | \n
It is possible for a schematic to provide all of its logic in the index.ts file, without additional templates.\nYou can create dynamic schematics for Angular, however, by providing components and templates in the files/ folder, like those in standalone Angular projects.\nThe logic in the index file configures these templates by defining rules that inject data and modify variables.