{"owner":"angular","repo":"angular-cli","hasSkills":true,"totalSkillsCount":18,"totalTokensCount":12602,"categories":["root-instruction","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","packages/README.md","packages/angular/cli/README.md","packages/angular/create/README.md","packages/angular/pwa/README.md","packages/angular/ssr/README.md","packages/angular_devkit/architect/README.md","packages/angular_devkit/architect/src/jobs/README.md","packages/angular_devkit/build_angular/README.md","packages/angular_devkit/build_webpack/README.md","packages/angular_devkit/core/README.md","packages/angular_devkit/schematics/README.md","packages/angular_devkit/schematics_cli/README.md","packages/angular_devkit/schematics_cli/blank/project-files/README.md","packages/angular_devkit/schematics_cli/schematic/files/README.md","packages/ngtools/webpack/README.md","packages/schematics/angular/README.md","tests/schematics/update/packages/README.md"],"skills":{"AGENTS.md":"---\ntrigger: always_on\n---\n\nThis is the source code for the Angular CLI and related build tooling. This guide outlines standard practices for AI agents working in this repository.\n\n## Environment\n\n- Use `pnpm` for package management.\n- Use `pnpm bazel test //target` to run tests.\n\n## Key Documentation\n\n- [Developer Guide](docs/DEVELOPER.md): definitive guide for building, debugging, and running test targets.\n- [Contributing Guide](CONTRIBUTING.md): general contribution workflows and guidelines.\n- [Commit Guidelines](CONTRIBUTING.md#commit): format for commit messages and PR titles.\n\n## Building\n\n- Make a local build of all packages:\n ```shell\n pnpm build --local\n ```\n\n## Coding Practices\n\n- **Imports:**\n - Always use the `node:` protocol for Node.js built-in imports (e.g., `node:fs`, `node:path`, `node:assert`).\n - Prefer named imports (e.g., `import { mkdtemp } from 'node:fs'`) or default imports (`import fs from 'node:fs'`) instead of namespace imports (`import * as fs`).\n - Use type-only imports (`import type { ... }`) when importing types to avoid runtime side-effects.\n- **Classes:**\n - Prefer ECMAScript private fields (`#field`) over TypeScript `private` keywords for encapsulated state.\n\n## Testing\n\n- **Temporary Directories (`TEST_TMPDIR`):**\n - Tests in this repository only run in Bazel. **ALWAYS** use `process.env['TEST_TMPDIR']` and assert that it is set:\n ```ts\n import assert from 'node:assert';\n import { mkdtemp } from 'node:fs/promises';\n import { join } from 'node:path';\n\n describe('...', () => {\n let tempRoot: string;\n\n beforeAll(async () => {\n const baseTmpDir = process.env['TEST_TMPDIR'];\n assert(baseTmpDir, 'TEST_TMPDIR is not set');\n tempRoot = await mkdtemp(join(baseTmpDir, 'angular-cli-test-'));\n });\n });\n ```\n - **NEVER** use or fallback to `os.tmpdir()`. Bazel executes tests in hermetic sandboxes and sets `TEST_TMPDIR` to an isolated, sandboxed directory. Using `os.tmpdir()` can cause sandboxing failures, permission errors, or file leakage outside the Bazel sandbox.\n- **Unit & Integration Tests:**\n - Run all unit and integration tests: `pnpm bazel test //packages/...`\n - Run a specific unit test target (e.g., `pnpm bazel test //packages/angular/build:test`). Note that package `:test` targets may exclude builder integration tests (such as specs under `**/builders/**/tests/**`).\n - Run a specific builder integration test target (e.g., `pnpm bazel test //packages/angular/build:library_integration_tests` or `pnpm bazel test //packages/angular/build:application_integration_tests`).\n - Query all test targets: `pnpm bazel query \"tests(//packages/...)\"`\n - Find the exact test target for a specific spec file (using its workspace-relative path, which Bazel resolves as a source file target): `pnpm bazel query \"kind(jasmine_test, rdeps(//packages/..., ))\"`\n - Focus specific tests when debugging: use `fdescribe()` and `fit()`. NEVER commit focused tests to the repository.\n - Run tests without sharding when isolating or debugging: use `--config=no-sharding` with a specific test target (e.g., `pnpm bazel test //packages/angular/build:library_integration_tests --config=no-sharding`).\n This disables test sharding (`--test_sharding_strategy=disabled`) and flaky test retries (`--flaky_test_attempts=1`).\n This is especially useful when isolating test runs or debugging with focused tests (`fit`/`fdescribe`) to avoid empty shard failures and unnecessary re-runs.\n Do not use this flag when running broad test suites (such as `//packages/...`), as executing tests without sharding takes significantly longer.\n- **End-to-End Tests:**\n - Run subset of E2E tests: `pnpm bazel test //tests:e2e_node22 --config=e2e --test_filter=\"\"`\n\n## Pull Requests\n\n- Use the `gh` CLI (GitHub CLI) for creating and managing pull requests.\n- **Fixup Commits:**\n - When addressing review feedback, **ALWAYS** use fixup commits (`git commit --fixup `) instead of amending existing commits. This preserves commit history during review and allows reviewers to easily see incremental changes.\n - Only use fixup commits for changes that directly belong to the target commit. Unrelated changes must be made in a separate commit with their own commit message, not as a fixup commit.\n - Fixup commits are automatically squashed when merging with `pnpm ng-dev pr merge` or optionally when rebasing with `pnpm ng-dev pr rebase `.\n- Use `pnpm ng-dev pr` commands:\n - `pnpm ng-dev pr rebase `: Rebase a PR branch on its target branch and optionally squash fixup commits.\n - `pnpm ng-dev pr merge `: Merge an approved PR into its targeted branches.\n","packages/README.md":"# `/packages` Folder\n\nThis folder is the root of all defined packages in this repository.\n\nPackages that are marked as `private: true` will not be published to NPM.\n\nThis folder includes a directory for every scope in NPM, without the `@` sign. Then one folder\nper package, which contains the `package.json`.\n","packages/angular/cli/README.md":"# Angular CLI - The CLI tool for Angular.\n\nThe sources for this package are in the [Angular CLI](https://github.com/angular/angular-cli) repository. Please file issues and pull requests against that repository.\n\nUsage information and reference details can be found in repository [README](https://github.com/angular/angular-cli/blob/main/README.md) file.\n","packages/angular/create/README.md":"# `@angular/create`\n\n## Create an Angular CLI workspace\n\nScaffold an Angular CLI workspace without needing to install the Angular CLI globally. All of the [ng new](https://angular.dev/cli/new) options and features are supported.\n\n## Usage\n\n### npm\n\n```\nnpm init @angular@latest [project-name] -- [...options]\n```\n\n### yarn\n\n```\nyarn create @angular [project-name] [...options]\n```\n\n### pnpm\n\n```\npnpm create @angular [project-name] [...options]\n```\n\n### bun\n\n```\nbun create @angular [project-name] [...options]\n```\n","packages/angular/pwa/README.md":"# `@angular/pwa`\n\nThis is a [schematic](https://angular.dev/tools/cli/schematics) for adding\n[Progressive Web App](https://web.dev/progressive-web-apps/) support to an Angular project. Run the\nschematic with the [Angular CLI](https://angular.dev/tools/cli):\n\n```shell\nng add @angular/pwa --project \n```\n\nExecuting the command mentioned above will perform the following actions:\n\n1. Adds [`@angular/service-worker`](https://npmjs.com/@angular/service-worker) as a dependency to your project.\n1. Enables service worker builds in the Angular CLI.\n1. Imports and registers the service worker in the application module.\n1. Updates the `index.html` file to inlclude a link to add the [manifest.webmanifest](https://developer.mozilla.org/en-US/docs/Web/Manifest) file.\n1. Installs icon files to support the installed Progressive Web App (PWA).\n1. Creates the service worker configuration file called `ngsw-config.json`, specifying caching behaviors and other settings.\n\nSee [Getting started with service workers](https://angular.dev/ecosystem/service-workers/getting-started)\nfor more information.\n","packages/angular/ssr/README.md":"# Angular SSR\n\nRead the dev guide [here](https://angular.dev/guide/ssr).\n","packages/angular_devkit/architect/README.md":"# Angular Build Facade\n\nWIP\n","packages/angular_devkit/architect/src/jobs/README.md":"# Description\n\nJobs is the Angular DevKit subsystem for scheduling and running generic functions with clearly\ntyped inputs and outputs. A `Job` instance is a function associated with metadata. You can\nschedule a job, synchronize it with other jobs, and use it to schedule other jobs.\n\nThe whole API is serializable, allowing you to use a Node Stream or message channel to\ncommunicate between the job and the job scheduler.\n\nJobs are lazy, cold, and guaranteed to execute exactly once when scheduled. Subscribing to a job\nreturns messages from the point where the job is at.\n\n## Argument, Input, Output and Channels\n\nA job receives a single argument when scheduled and can also listen to an input channel. It can\nemit multiple outputs, and can also provide multiple output channels that emit asynchronous JSON\nmessages, which can be typed.\n\nThe I/O model is like that of an executable, where the argument corresponds to arguments on the\ncommand line, the input channel to STDIN, the output channel to STDOUT, and the channels\nwould be additional output streams.\n\n## LifeCycle\n\nA `Job` goes through multiple LifeCycle messages before its completion;\n\n1. `JobState.Queued`. The job was queued and is waiting. This is the default state from the\n scheduler.\n1. `JobState.Ready`. The job's dependencies (see\n [\"Synchronizing and Dependencies\"](#Dependencies)) are done running, the argument is\n validated, and the job is ready to execute.\n1. `JobState.Started`. The argument has been validated, the job has been called and is running.\n This is handled by the job itself (or `createJobHandler()`).\n1. `JobState.Ended`. The job has ended and is done running. This is handled by the job itself (or\n `createJobHandler()`).\n1. `JobState.Errored`. A unrecoverable error happened.\n\nEach state (except `Queued`) corresponds to a `JobOutboundMessage` on the `outboundBus` observable\nthat triggers the state change. The `Scheduler` emits the `Ready` and `Errored` messages; the job\nimplementation should not emit them, and if it does they are filtered out. You can listen for\nthese messages or use the corresponding state member.\n\nThe job implementation should emit the `Start` and `End` messages when it is starting the job logic\nitself. Only the first `Start` and `End` messages will be forwarded. Any more will be filtered out.\n\nThe `Queued` state is set as the job is scheduled, so there is no need to listen for the message.\n\n## `Job` Object\n\nThe `Job` object that is returned when you schedule a job provides access to the job's status and\nutilities for tracking and modifying the job.\n\n1. `id`. A unique symbol that can be used as a Map key.\n1. `description`. The description of the job from the scheduler. See `JobDescription` object.\n1. `argument`. The argument value that was used to start the job.\n1. `input`. An `Observer` that can be used to send validated inputs to the job itself.\n1. `output`. An `Observable` that filters out messages to get only the returned output\n of a job.\n1. `promise`. A promise that waits for the last output of a job. Returns the last value outputted\n (or no value if there's no last value).\n1. `state`. The current state of the job (see `LifeCycle`).\n1. `channels`. A map of side channels the user can listen to as `Observable`.\n1. `ping()`. A function that can be used to ping the job, receiving a `Promise` for when the ping\n is answered.\n1. `stop()`. Sends a `stop` input to the job, which suggests to stop the job. The job itself can\n choose to ignore this message.\n1. `inboundBus`. The raw input `Observer`. This can be used to send messages to\n the `context.inboundBus` observable in the job. These are `JobInboundMessage` messages. See\n [\"Communicating With Jobs\"](#Communicating).\n1. `outboundBus`. The raw output `Observable`. This can be used to listen to messages\n from the job. See [\"Communicating With Jobs\"](#Communicating).\n\n## `JobHandlerContext` Object\n\nThe `JobHandlerContext<>` is passed to the job handler code in addition to its argument. The\ncontext contains the following members:\n\n1. `description`. The description of the job. Its name and schemas.\n1. `scheduler`. A `Scheduler<>` instance that can be used to create additional jobs.\n1. `dependencies`. A generic list of other job instances that were run as dependencies when\n scheduling this job. Their `id` is not guaranteed to match the `id` of the `Job<>` instance\n itself (those `Job<>`s might just be proxies). The state of those `Job<>` is guaranteed to be\n `JobState.Ended`, as `JobState.Errored` would have prevented this handler from running.\n1. `inboundBus`. The raw input observable, complement of the `inboundBus` observer from the `Job<>`.\n\n# Examples\n\nAn example of a job that adds all input together and return the output value. We use a\nsimple synchronous job registry and a simple job scheduler.\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\nconst add = jobs.createJobHandle((input) =>\n input.reduce((total, curr) => total + curr, 0),\n);\n\n// Register the job in a SimpleJobRegistry. Different registries have different API.\nconst registry = new jobs.SimpleJobRegistry();\nconst scheduler = new jobs.SimpleScheduler(registry);\nregistry.register(add, {\n name: 'add',\n input: { type: 'array', items: { type: 'number' } },\n output: { type: 'number' },\n});\n\nscheduler\n .schedule('add', [1, 2, 3, 4])\n .promise.then((output) => console.log('1 + 2 + 3 + 4 is ' + output));\n```\n\n# Creating Jobs\n\nA job is at its core a function with a description object attached to it. The description object\nstores the JSON schemas used to validate the types of the argument passed in, the input and\noutput values. By default, a job accepts and can output any JSON object.\n\n```typescript\nimport { Observable } from 'rxjs';\nimport { jobs } from '@angular-devkit/core';\n\nconst argument = {\n type: 'array',\n items: { type: 'number' },\n};\nconst output = {\n type: 'number',\n};\n\nexport function add(argument: number[]): Observable> {\n return new Observable((o) => {\n o.next({ kind: jobs.JobOutboundMessageKind.Start });\n o.next({\n kind: jobs.JobOutboundMessageKind.Output,\n output: argument.reduce((total, curr) => total + curr, 0),\n });\n o.next({ kind: jobs.JobOutboundMessageKind.End });\n o.complete();\n });\n}\n\n// Add a property to `add` to make it officially a JobHandler. The Job system does not recognize\n// any function as a JobHandler.\nadd.jobDescription = {\n argument: argument,\n output: output,\n};\n\n// Call the job with an array as argument, and log its output.\ndeclare const scheduler: jobs.Scheduler;\nscheduler.schedule('add', [1, 2, 3, 4]).output.subscribe((x) => console.log(x)); // Will output 10.\n```\n\nThis is a lot of boilerplate, so we made some helpers to improve readability and manage argument,\ninput and output automatically:\n\n```typescript\n// Add is a JobHandler function, like the above.\nexport const add = jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n);\n\n// Schedule like above.\n```\n\nYou can also return a Promise or an Observable, as jobs are asynchronous. This helper will set\nstart and end messages appropriately. It will also manage channels automatically (see below).\n\nA more complex job can be declared like this:\n\n```typescript\nimport { Observable } from 'rxjs';\nimport { jobs } from '@angular-devkit/core';\n\n// Show progress with each count in a separate output channel. Output \"more\" in a channel.\nexport const count = jobs.createJobHandler(\n // Receive a context that contains additional methods to create channels.\n (argument: number, { createChannel }) =>\n new Observable((o) => {\n const side = createChannel('side', { type: 'string', const: 'more' });\n const progress = createChannel('progress', { type: 'number' });\n let i = 0;\n function doCount() {\n o.next(i++);\n progress.next(i / argument);\n side.next('more');\n\n if (i < argument) {\n setTimeout(doCount, 100);\n } else {\n o.complete();\n }\n }\n setTimeout(doCount, 100);\n }),\n {\n argument: { type: 'number' },\n output: { type: 'number' },\n },\n);\n\n// Get a hold of a scheduler that refers to the job above.\ndeclare const scheduler: jobs.Scheduler;\n\nconst job = scheduler.schedule('count', 0);\njob.getChannel('side').subscribe((x) => console.log(x));\n// You can type a channel too. Messages will be filtered out.\njob.getChannel('progress', { type: 'number' }).subscribe((x) => console.log(x));\n```\n\n## Communicating With Jobs\n\nJobs can be started and updated in a separate process or thread, and as such communication with a\njob should avoid using global objects (which might not be shared). The jobs API and schedulers\nprovide 2 communication streams (one for input and the other for output), named `inboundBus` and\n`outboundBus`.\n\n### Raw Input Stream\n\nThe `schedule()` function returns a `Job<>` interface that contains a `inboundBus` member of type\n`Observer`. All messages sent _to_ the job goes through this stream. The `kind`\nmember of the `JobInboundMessage` interface dictates what kind of message it is sending:\n\n1. `JobInboundMessageKind.Ping`. A simple message that should be answered with\n `JobOutboundMessageKind.Pong` when the job is responsive. The `id` field of the message should\n be used when returning `Pong`.\n1. `JobInboundMessageKind.Stop`. The job should be stopped. This is used when\n cancelling/unsubscribing from the `output` (or by calling `stop()`). Any inputs or outputs\n after this message will be ignored.\n1. `JobInboundMessageKind.Input` is used when sending inputs to a job. These correspond to the\n `next` methods of an `Observer` and are reported to the job through its `context.input`\n Observable. There is no way to communicate an error to the job.\n\nUsing the `createJobHandler()` helper, all those messages are automatically handled by the\nboilerplate code. If you need direct access to raw inputs, you should subscribe to the\n`context.inboundBus` Observable.\n\n### Raw Output Stream\n\nThe `Job<>` interface also contains a `outboundBus` member (of type\n`Observable>` where `O` is the typed output of the job) which is the output\ncomplement of `inboundBus`. All messages sent _from_ the job goes through this stream. The `kind`\nmember of the `JobOutboundMessage` interface dictates what kind of message it is sending:\n\n1. `JobOutboundMessageKind.Create`. The `Job<>` was created, its dependencies are done, and the\n library is validating Argument and calling the internal job code.\n1. `JobOutboundMessageKind.Start`. The job code itself should send that message when started.\n `createJobHandler()` will do it automatically.\n1. `JobOutboundMessageKind.End`. The job has ended. This is done by the job itself and should always\n be sent when completed. The scheduler will listen to this message to set the state and unblock\n dependent jobs. `createJobHandler()` automatically send this message.\n1. `JobOutboundMessageKind.Pong`. The job should answer a `JobInboundMessageKind.Ping` message with\n this. Automatically done by `createJobHandler()`.\n1. `JobOutboundMessageKind.Output`. An `Output` has been generated by the job.\n1. `JobOutboundMessageKind.ChannelMessage`, `JobOutboundMessageKind.ChannelError` and\n `JobOutboundMessageKind.ChannelComplete` are used for output channels. These correspond to the\n `next`, `error` and `complete` methods of an `Observer` and are available to the callee through\n the `job.channels` map of Observable.\n\nThose messages can be accessed directly through the `job.outboundBus` member. The job itself should\nreturn an `Observable>`. The `createJobHandler()` helper handles most of use\ncases of this and makes it easier for jobs to handle this.\n\n## Job Dispatchers\n\nDispatchers are a helper that redirect to different jobs given conditions. To create a job\ndispatcher, use the `createDispatcher()` function:\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\n// A dispatcher that installs node modules given a user's preference.\nconst dispatcher = jobs.createDispatcher({\n name: 'node-install',\n argument: { properties: { moduleName: { type: 'string' } } },\n output: { type: 'boolean' },\n});\n\nconst npmInstall = jobs.createJobHandler(/* ... */, { name: 'npm-install' });\nconst yarnInstall = jobs.createJobHandler(/* ... */, { name: 'yarn-install' });\nconst pnpmInstall = jobs.createJobHandler(/* ... */, { name: 'pnpm-install' });\n\ndeclare const registry: jobs.SimpleJobRegistry;\nregistry.register(dispatcher);\nregistry.register(npmInstall);\nregistry.register(yarnInstall);\nregistry.register(pnpmInstall);\n\n// Default to npm.\ndispatcher.setDefaultDelegate(npmInstall.name);\n// If the user is asking for yarn over npm, uses it.\ndispatcher.addConditionalDelegate(() => userWantsYarn, yarnInstall.name);\n```\n\n## Execution Strategy\n\nJobs are always run in parallel and will always start, but many helper functions are provided\nwhen creating a job to help you control the execution strategy;\n\n1. `serialize()`. Multiple runs of this job will be queued with each others.\n1. `memoize(replayMessages = false)` will create a job, or reuse the same job when inputs are\n matching. If the inputs don't match, a new job will be started and its outputs will be stored.\n\nThese strategies can be used when creating the job:\n\n```typescript\n// Same input and output as above.\n\nexport const add = jobs.strategy.memoize()(\n jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n ),\n);\n```\n\nStrategies can be reused to synchronize between jobs. For example, given jobs `jobA` and `jobB`,\nyou can reuse the strategy to serialize both jobs together;\n\n```typescript\nconst strategy = jobs.strategy.serialize();\nconst jobA = strategy(jobs.createJobHandler(...));\nconst jobB = strategy(jobs.createJobHandler(...));\n```\n\nEven further, we can have package A and package B run in serialization, and B and C also be\nserialized. Running A and C will run in parallel, while running B will wait for both A and C\nto finish.\n\n```typescript\nconst strategy1 = jobs.strategy.serialize();\nconst strategy2 = jobs.strategy.serialize();\nconst jobA = strategy1(jobs.createJobHandler(...));\nconst jobB = strategy1(strategy2(jobs.createJobHandler(...)));\nconst jobC = strategy2(jobs.createJobHandler(...));\n```\n\n# Scheduling Jobs\n\nJobs can be scheduled using a `Scheduler` interface, which contains a `schedule()` method:\n\n```typescript\ninterface Scheduler {\n /**\n * Schedule a job to be run, using its name.\n * @param name The name of job to be run.\n * @param argument The argument to send to the job when starting it.\n * @param options Scheduling options.\n * @returns The Job being run.\n */\n schedule(\n name: JobName,\n argument: I,\n options?: ScheduleJobOptions,\n ): Job;\n}\n```\n\nThe scheduler also has a `getDescription()` method to get a `JobDescription` object for a certain\nname; that description contains schemas for the argument, input, output, and other channels:\n\n```typescript\ninterface Scheduler {\n /**\n * Get a job description for a named job.\n *\n * @param name The name of the job.\n * @returns A description, or null if the job cannot be scheduled.\n */\n getDescription(name: JobName): JobDescription | null;\n\n /**\n * Returns true if the job name has been registered.\n * @param name The name of the job.\n * @returns True if the job exists, false otherwise.\n */\n has(name: JobName): boolean;\n}\n```\n\nFinally, the scheduler interface has a `pause()` method to stop scheduling. This will queue all\njobs and wait for the unpause function to be called before unblocking all the jobs scheduled.\nThis does not affect already running jobs.\n\n```typescript\ninterface Scheduler {\n /**\n * Pause the scheduler, temporary queueing _new_ jobs. Returns a resume function that should be\n * used to resume execution. If multiple `pause()` were called, all their resume functions must\n * be called before the Scheduler actually starts new jobs. Additional calls to the same resume\n * function will have no effect.\n *\n * Jobs already running are NOT paused. This is pausing the scheduler only.\n *\n * @returns A function that can be run to resume the scheduler. If multiple `pause()` calls\n * were made, all their return function must be called (in any order) before the\n * scheduler can resume.\n */\n pause(): () => void;\n}\n```\n\n## Synchronizing and Dependencies\n\nWhen scheduling jobs, it is often necessary to run jobs after certain other jobs are finished.\nThis is done through the `dependencies` options in the `schedule()` method.\n\nThese jobs will also be passed to the job being scheduled, through its context. This can be\nuseful if, for example, the output of those jobs are of a known type, or have known side channels.\n\nAn example of this would be a compiler that needs to know the output directory of other compilers\nbefore it, in a tool chain.\n\n### Dependencies\n\nWhen scheduling jobs, the user can add a `dependencies` field to the scheduling options. The\nscheduler will wait for those dependencies to finish before running the job, and pass those jobs\nin the context of the job.\n\n### Accessing Dependencies\n\nJobs are called with a `JobHandlerContext` as a second argument, which contains a\n`dependencies: Job[]` member which contains all dependencies that were used when\nscheduling the job. Those aren't fully typed as they are determined by the user, and not the job\nitself. They also can contain jobs that are not finished, and the job should use the `state`\nmember of the job itself before trying to access its content.\n\n### Scheduler Sub Jobs\n\nThe `JobHandlerContext` also contains a `scheduler` member which can be used to schedule jobs\nusing the same scheduler that was used for the job. This allows jobs to call other jobs\nand wait for them to end.\n\n## Available Schedulers\n\nThe Core Angular DevKit library provides 2 implementations for the `Scheduler` interface:\n\n## SimpleJobRegistry\n\nAvailable in the jobs namespace. A registry that accept job registration, and can also schedule\njobs.\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\nconst add = jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n);\n\n// Register the job in a SimpleJobRegistry. Different registries have different API.\nconst registry = new jobs.SimpleJobRegistry();\nconst scheduler = new SimpleJobScheduler(registry);\n\nregistry.register(add, {\n name: 'add',\n argument: { type: 'array', items: { type: 'number' } },\n output: { type: 'number' },\n});\n\nscheduler.schedule('add', [1, 2, 3, 4]);\n```\n\n## NodeModuleJobRegistry\n\nAvailable through `@angular-devkit/core/node`.\n\nA scheduler that loads jobs using their node package names. These jobs need to use the\n`createJobHandler()` helper and report their argument/input/output schemas that way.\n\n```typescript\ndeclare const registry: NodeModuleJobRegistry;\nconst scheduler = new SimpleJobScheduler(registry);\n\nscheduler.schedule('some-node-package#someExport', 'input');\n```\n\n# Gotchas\n\n1. Deadlocking Dependencies \n It is impossible to add dependencies to an already running job, but it is entirely possible to\n get locked between jobs. Be aware of your own dependencies.\n\n1. Using `job.promise` \n `job.promise` waits for the job to ends. Don't rely on it unless you know the job is not\n watching and running for a long time. If you aren't sure, use\n `job.output.pipe(first()).toPromise()` instead which will return the first next output,\n regardless of whether the job watches and rerun or not.\n\n# FAQ\n\n1. Laziness \n A job is lazy until executed, but its messages will be replayed when resubscribed.\n\n1. Serialize Strategy vs Dependencies \n Strategies are functions that transform the execution of a job, and can be used when\n declaring the job, or registering it. Dependencies, on the other hand, are listed when\n scheduling a job to order jobs during scheduling.\n\n A job has no control over the way it's scheduled, and its dependencies. It can, however,\n declare that it shouldn't run at the same time as itself. Alternatively, a user could\n schedule a job twice and imply that the second run should wait for the first to finish. In\n practice, this would be equivalent to having the job be serialized, but the important detail\n is in _whom_ is defining the rules; using the `serialize()` strategy, the job implementation\n is, while when using dependencies, the user is.\n\n The user does not need to know how to job needs to synchronize with itself, and the job does\n not need to know how it synchronizes with other jobs that it doesn't know about. That's part\n of the strength of this system as every job can be developed in a vacuum, only caring about\n its contracts (argument, input and output) and its own synchronization.\n","packages/angular_devkit/build_angular/README.md":"# @angular-devkit/build-angular\n\nThis package contains [Architect builders](/packages/angular_devkit/architect/README.md) used to build and test Angular applications and libraries.\n\n## Builders\n\n| Name | Description |\n| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| application | Build an Angular application targeting a browser and server environment using [esbuild](https://esbuild.github.io). |\n| app-shell | Build an Angular [App shell](https://angular.dev/ecosystem/service-workers/app-shell). |\n| browser | Build an Angular application targeting a browser environment using [Webpack](https://webpack.js.org). |\n| browser-esbuild | Build an Angular application targeting a browser environment using [esbuild](https://esbuild.github.io). |\n| dev-server | A development server that provides live reloading. |\n| extract-i18n | Extract i18n messages from an Angular application. |\n| karma | Execute unit tests using [Karma](https://github.com/karma-runner/karma) test runner. |\n| ng-packagr | Build and package an Angular library in [Angular Package Format (APF)](https://angular.dev/tools/libraries/angular-package-format) format using [ng-packagr](https://github.com/ng-packagr/ng-packagr). |\n| prerender | [Prerender](https://angular.dev/guide/prerendering) pages of your application. Prerendering is the process where a dynamic page is processed at build time generating static HTML. |\n| server | Build an Angular application targeting a [Node.js](https://nodejs.org) environment. |\n| ssr-dev-server | A development server which offers live reload during development, but uses server-side rendering. |\n\n## Disclaimer\n\nWhile the builders when executed via the Angular CLI and their associated options are considered stable, the programmatic APIs are not considered officially supported and are not subject to the breaking change guarantees of SemVer.\n","packages/angular_devkit/build_webpack/README.md":"# Webpack Builder for Architect\n\nThis package allows you to run Webpack and Webpack Dev Server using Architect.\n\nTo use it on your Angular CLI app, follow these steps:\n\n- run `npm install @angular-devkit/build-webpack`.\n- create a webpack configuration.\n- add the following targets inside `angular.json`.\n\n```\n \"projects\": {\n \"app\": {\n // ...\n \"architect\": {\n // ...\n \"build-webpack\": {\n \"builder\": \"@angular-devkit/build-webpack:webpack\",\n \"options\": {\n \"webpackConfig\": \"webpack.config.js\"\n }\n },\n \"serve-webpack\": {\n \"builder\": \"@angular-devkit/build-webpack:webpack-dev-server\",\n \"options\": {\n \"webpackConfig\": \"webpack.config.js\"\n }\n }\n }\n```\n\n- run `ng run app:build-webpack` to build, and `ng run app:serve-webpack` to serve.\n\nAll options, including `watch` and `stats`, are looked up inside the webpack configuration.\n","packages/angular_devkit/core/README.md":"# Core\n\n> Shared utilities for Angular DevKit.\n\n# Exception\n\n# Json\n\n## Schema\n\n### SchemaValidatorResult\n\n```\nexport interface SchemaValidatorResult {\n success: boolean;\n errors?: string[];\n}\n```\n\n### SchemaValidator\n\n```\nexport interface SchemaValidator {\n (data: any): Observable;\n}\n```\n\n### SchemaFormatter\n\n```\nexport interface SchemaFormatter {\n readonly async: boolean;\n validate(data: any): boolean | Observable;\n}\n```\n\n### SchemaRegistry\n\n```\nexport interface SchemaRegistry {\n compile(schema: Object): Observable;\n addFormat(name: string, formatter: SchemaFormatter): void;\n}\n```\n\n### CoreSchemaRegistry\n\n`SchemaRegistry` implementation using https://github.com/epoberezkin/ajv.\nConstructor accepts object containing `SchemaFormatter` that will be added automatically.\n\n```\nexport class CoreSchemaRegistry implements SchemaRegistry {\n constructor(formats: { [name: string]: SchemaFormatter} = {}) {}\n}\n```\n\n# Logger\n\n# Utils\n\n# Virtual FS\n\n# Workspaces\n\nThe `workspaces` namespace provides an API for interacting with the workspace file formats.\nIt provides an abstraction of the underlying storage format of the workspace and provides\nsupport for both reading and writing. Currently, the only supported format is the JSON-based\nformat used by the Angular CLI. For this format, the API provides internal change tracking of values which\nenables fine-grained updates to the underlying storage of the workspace. This allows for the\nretention of existing formatting and comments.\n\nA workspace is defined via the following object model. Definition collection objects are specialized\nJavascript `Map` objects with an additional `add` method to simplify addition and provide more localized\nerror checking of the newly added values.\n\n```ts\nexport interface WorkspaceDefinition {\n readonly extensions: Record;\n readonly projects: ProjectDefinitionCollection;\n}\n\nexport interface ProjectDefinition {\n readonly extensions: Record;\n readonly targets: TargetDefinitionCollection;\n root: string;\n prefix?: string;\n sourceRoot?: string;\n}\n\nexport interface TargetDefinition {\n options?: Record;\n configurations?: Record | undefined>;\n builder: string;\n}\n```\n\nThe API is asynchronous and has two main functions to facilitate reading, creation, and modifying\na workspace: `readWorkspace` and `writeWorkspace`.\n\n```ts\nexport enum WorkspaceFormat {\n JSON,\n}\n```\n\n```ts\nexport function readWorkspace(\n path: string,\n host: WorkspaceHost,\n format?: WorkspaceFormat,\n): Promise<{ workspace: WorkspaceDefinition }>;\n```\n\n```ts\nexport function writeWorkspace(\n workspace: WorkspaceDefinition,\n host: WorkspaceHost,\n path?: string,\n format?: WorkspaceFormat,\n): Promise;\n```\n\nA `WorkspaceHost` abstracts the underlying data access methods from the functions. It provides\nmethods to read, write, and analyze paths. A utility function is provided to create\nan instance of a `WorkspaceHost` from the Angular DevKit's virtual filesystem host abstraction.\n\n```ts\nexport interface WorkspaceHost {\n readFile(path: string): Promise;\n writeFile(path: string, data: string): Promise;\n isDirectory(path: string): Promise;\n isFile(path: string): Promise;\n}\n\nexport function createWorkspaceHost(host: virtualFs.Host): WorkspaceHost;\n```\n\n## Usage Example\n\nTo demonstrate the usage of the API, the following code will show how to add a option property\nto a build target for an application.\n\n```ts\nimport { NodeJsSyncHost } from '@angular-devkit/core/node';\nimport { workspaces } from '@angular-devkit/core';\n\nasync function demonstrate() {\n const host = workspaces.createWorkspaceHost(new NodeJsSyncHost());\n const { workspace } = await workspaces.readWorkspace('path/to/workspace/directory/', host);\n\n const project = workspace.projects.get('my-app');\n if (!project) {\n throw new Error('my-app does not exist');\n }\n\n const buildTarget = project.targets.get('build');\n if (!buildTarget) {\n throw new Error('build target does not exist');\n }\n\n buildTarget.options.optimization = true;\n\n await workspaces.writeWorkspace(workspace, host);\n}\n\ndemonstrate();\n```\n","packages/angular_devkit/schematics/README.md":"# Schematics\n\n> A scaffolding library for the modern web.\n\n## Description\n\nSchematics are generators that transform an existing filesystem. They can create files, refactor existing files, or move files around.\n\nWhat distinguishes Schematics from other generators, such as Yeoman or Yarn Create, is that schematics are purely descriptive; no changes are applied to the actual filesystem until everything is ready to be committed. There is no side effect, by design, in Schematics.\n\n# Glossary\n\n| Term | Description |\n| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Schematics** | A generator that executes descriptive code without side effects on an existing file system. |\n| **Collection** | A list of schematics metadata. Schematics can be referred by name inside a collection. |\n| **Tool** | The code using the Schematics library. |\n| **Tree** | A staging area for changes, containing the original file system, and a list of changes to apply to it. |\n| **Rule** | A function that applies actions to a `Tree`. It returns a new `Tree` that will contain all transformations to be applied. |\n| **Source** | A function that creates an entirely new `Tree` from an empty filesystem. For example, a file source could read files from disk and create a Create Action for each of those. |\n| **Action** | An atomic operation to be validated and committed to a filesystem or a `Tree`. Actions are created by schematics. |\n| **Sink** | The final destination of all `Action`s. |\n| **Task** | A Task is a way to execute an external command or script in a schematic. A Task can be used to perform actions such as installing dependencies, running tests, or building a project. A Task is created by using the `SchematicContext` object and can be scheduled to run before or after the schematic `Tree` is applied. |\n\n# Tooling\n\nSchematics is a library, and does not work by itself. A [reference CLI](https://github.com/angular/angular-cli/blob/main/packages/angular_devkit/schematics_cli/bin/schematics.ts) is available on this repository, and is published on NPM at [@angular-devkit/schematics-cli](https://www.npmjs.com/package/@angular-devkit/schematics-cli). This document explains the library usage and the tooling API, but does not go into the tool implementation itself.\n\nThe tooling is responsible for the following tasks:\n\n1. Create the Schematic Engine, and pass in a Collection and Schematic loader.\n1. Understand and respect the Schematics metadata and dependencies between collections. Schematics can refer to dependencies, and it's the responsibility of the tool to honor those dependencies. The reference CLI uses NPM packages for its collections.\n1. Create the Options object. Options can be anything, but the schematics can specify a JSON Schema that should be respected. The reference CLI, for example, parses the arguments as a JSON object and validates it with the Schema specified by the collection.\n1. Schematics provides some JSON Schema formats for validation that tooling should add. These validate paths, html selectors and app names. Please check the reference CLI for how these can be added.\n1. Call the schematics with the original Tree. The tree should represent the initial state of the filesystem. The reference CLI uses the current directory for this.\n1. Create a Sink and commit the result of the schematics to the Sink. Many sinks are provided by the library; FileSystemSink and DryRunSink are examples.\n1. Output any logs propagated by the library, including debugging information.\n\nThe tooling API is composed of the following pieces:\n\n## Engine\n\nThe `SchematicEngine` is responsible for loading and constructing `Collection`s and `Schematics`. When creating an engine, the tooling provides an `EngineHost` interface that understands how to create a `CollectionDescription` from a name, and how to create a `SchematicDescription`.\n\n# Schematics (Generators)\n\nSchematics are generators and part of a `Collection`.\n\n## Collection\n\nA Collection is defined by a `collection.json` file (in the reference CLI). This JSON defines the following properties:\n\n| Prop Name | Type | Description |\n| ----------- | -------- | --------------------------- |\n| **name** | `string` | The name of the collection. |\n| **version** | `string` | Unused field. |\n\n## Schematic\n\n# Operators, Sources and Rules\n\nA `Source` is a generator of a `Tree`; it creates an entirely new root tree from nothing. A `Rule` is a transformation from one `Tree` to another. A `Schematic` (at the root) is a `Rule` that is normally applied on the filesystem.\n\n## Operators\n\n`FileOperator`s apply changes to a single `FileEntry` and return a new `FileEntry`. The result follows these rules:\n\n1. If the `FileEntry` returned is null, a `DeleteAction` will be added to the action list.\n1. If the path changed, a `RenameAction` will be added to the action list.\n1. If the content changed, an `OverwriteAction` will be added to the action list.\n\nIt is impossible to create files using a `FileOperator`.\n\n## Provided Operators\n\nThe Schematics library provides multiple `Operator` factories by default that cover basic use cases:\n\n| FileOperator | Description |\n| -------------------------------- | -------------------------------------------------------------------- |\n| `contentTemplate(options: T)` | Apply a content template (see the [Templating](#templating) section) |\n| `pathTemplate(options: T)` | Apply a path template (see the [Templating](#templating) section) |\n\n## Provided Sources\n\nThe Schematics library additionally provides multiple `Source` factories by default:\n\n| Source | Description |\n| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |\n| `empty()` | Creates a source that returns an empty `Tree`. |\n| `source(tree: Tree)` | Creates a `Source` that returns the `Tree` passed in as argument. |\n| `url(url: string)` | Loads a list of files from the given URL and returns a `Tree` with the files as `CreateAction` applied to an empty `Tree`. |\n| `apply(source: Source, rules: Rule[])` | Apply a list of `Rule`s to a source, and return the resulting `Source`. |\n\n## Provided Rules\n\nThe schematics library also provides `Rule` factories by default:\n\n| Rule | Description |\n| ------------------------------------------- | -------------------------------------------------------------------------------------- |\n| `noop()` | Returns the input `Tree` as is. |\n| `chain(rules: Rule[])` | Returns a `Rule` that's the concatenation of other `Rule`s. |\n| `forEach(op: FileOperator)` | Returns a `Rule` that applies an operator to every file of the input `Tree`. |\n| `move(root: string)` | Moves all the files from the input to a subdirectory. |\n| `merge(other: Tree)` | Merge the input `Tree` with the other `Tree`. |\n| `contentTemplate(options: T)` | Apply a content template (see the Template section) to the entire `Tree`. |\n| `pathTemplate(options: T)` | Apply a path template (see the Template section) to the entire `Tree`. |\n| `template(options: T)` | Apply both path and content templates (see the Template section) to the entire `Tree`. |\n| `filter(predicate: FilePredicate)` | Returns the input `Tree` with files that do not pass the `FilePredicate`. |\n\n# Templating\n\nAs referenced above, some functions are based upon a file templating system, which consists of path and content templating.\n\nThe system operates on placeholders defined inside files or their paths as loaded in the `Tree` and fills these in as defined in the following, using values passed into the `Rule` which applies the templating (i.e. `template(options: T)`).\n\n## Path Templating\n\n| Placeholder | Description |\n| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- |\n| `__variable__` | Replaced with the value of `variable`. |\n| `__variable@function__` | Replaced with the result of the call `function(variable)`. Can be chained to the left (`__variable@function1@function2__ ` etc). |\n\n## Content Templating\n\n| Placeholder | Description |\n| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |\n| `<%= expression %>` | Replaced with the result of the call of the given expression. This only supports direct expressions, no structural (for/if/...) JavaScript. |\n| `<%- expression %>` | Same as above, but the value of the result will be escaped for HTML when inserted (i.e. replacing '<' with '\\<') |\n| `<% inline code %>` | Inserts the given code into the template structure, allowing to insert structural JavaScript. |\n| `<%# text %>` | A comment, which gets entirely dropped. |\n\n# Examples\n\n## Simple\n\nAn example of a simple Schematics which creates a \"hello world\" file, using an option to determine its path:\n\n```typescript\nimport { Tree } from '@angular-devkit/schematics';\n\nexport default function MySchematic(options: any) {\n return (tree: Tree) => {\n tree.create(options.path + '/hi', 'Hello world!');\n return tree;\n };\n}\n```\n\nA few things from this example:\n\n1. The function receives the list of options from the tooling.\n1. It returns a [`Rule`](src/engine/interface.ts#L73), which is a transformation from a `Tree` to another `Tree`.\n\n## Templating\n\nA simplified example of a Schematics which creates a file containing a new Class, using an option to determine its name:\n\n```typescript\n// files/__name@dasherize__.ts\n\nexport class <%= classify(name) %> {\n}\n```\n\n```typescript\n// index.ts\n\nimport { strings } from '@angular-devkit/core';\nimport {\n Rule,\n SchematicContext,\n SchematicsException,\n Tree,\n apply,\n branchAndMerge,\n mergeWith,\n template,\n url,\n} from '@angular-devkit/schematics';\nimport { Schema as ClassOptions } from './schema';\n\nexport default function (options: ClassOptions): Rule {\n return (tree: Tree, context: SchematicContext) => {\n if (!options.name) {\n throw new SchematicsException('Option (name) is required.');\n }\n\n const templateSource = apply(url('./files'), [\n template({\n ...strings,\n ...options,\n }),\n ]);\n\n return branchAndMerge(mergeWith(templateSource));\n };\n}\n```\n\nAdditional things from this example:\n\n1. `strings` provides the used `dasherize` and `classify` functions, among others.\n1. The files are on-disk in the same root directory as the `index.ts` and loaded into a `Tree`.\n1. Then the `template` `Rule` fills in the specified templating placeholders. For this, it only knows about the variables and functions passed to it via the options-object.\n1. Finally, the resulting `Tree`, containing the new file, is merged with the existing files of the project which the Schematic is run on.\n","packages/angular_devkit/schematics_cli/README.md":"# Schematics CLI\n\nThis package contains the executable for running a [Schematic](/packages/angular_devkit/schematics/README.md).\n\n# Usage\n\n```\n$ schematics [CollectionName:]SchematicName [options, ...]\n\nBy default, if the collection name is not specified, use the internal collection provided\nby the Schematics CLI.\n\nOptions:\n --debug Debug mode. This is true by default if the collection is a relative\n path (in that case, turn off with --debug=false).\n\n --allow-private Allow private schematics to be run from the command line. Default to\n false.\n\n --dry-run Do not output anything, but instead just show what actions would be\n performed. Default to true if debug is also true.\n\n --force Force overwriting files that would otherwise be an error.\n\n --list-schematics List all schematics from the collection, by name. A collection name\n should be suffixed by a colon. Example: '@angular-devkit/schematics-cli:'.\n\n --no-interactive Disables interactive input prompts.\n\n --verbose Show more information.\n\n --help Show this message.\n\nAny additional option is passed to the Schematics depending on its schema.\n```\n\n# Examples\n\n1. Create a new NPM package that contains a blank schematic.\n\n```sh\n$ schematics blank \n```\n\n2. Walkthrough example that demonstrates how to build a schematic.\n\n```sh\n$ schematics schematic --name \n```\n","packages/angular_devkit/schematics_cli/blank/project-files/README.md":"# Getting Started With Schematics\n\nThis repository is a basic Schematic implementation that serves as a starting point to create and publish Schematics to NPM.\n\n### Testing\n\nTo test locally, install `@angular-devkit/schematics-cli` globally and use the `schematics` command line tool. That tool acts the same as the `generate` command of the Angular CLI, but also has a debug mode.\n\nCheck the documentation with\n\n```bash\nschematics --help\n```\n\n### Unit Testing\n\n`npm run test` will run the unit tests, using Jasmine as a runner and test framework.\n\n### Publishing\n\nTo publish, simply do:\n\n```bash\nnpm run build\nnpm publish\n```\n\nThat's it!\n","packages/angular_devkit/schematics_cli/schematic/files/README.md":"# Getting Started With Schematics\n\nThis repository is a basic Schematic implementation that serves as a starting point to create and publish Schematics to NPM.\n\n### Testing\n\nTo test locally, install `@angular-devkit/schematics-cli` globally and use the `schematics` command line tool. That tool acts the same as the `generate` command of the Angular CLI, but also has a debug mode.\n\nCheck the documentation with\n\n```bash\nschematics --help\n```\n\n### Unit Testing\n\n`npm run test` will run the unit tests, using Jasmine as a runner and test framework.\n\n### Publishing\n\nTo publish, simply do:\n\n```bash\nnpm run build\nnpm publish\n```\n\nThat's it!\n","packages/ngtools/webpack/README.md":"# Angular Compiler Webpack Plugin\n\nWebpack 5.x plugin for the Angular Ahead-of-Time compiler. The plugin also supports Angular JIT mode.\nWhen this plugin is used outside of the Angular CLI, the Ivy linker will also be needed to support\nthe usage of Angular libraries. An example configuration of the Babel-based Ivy linker is provided\nin the linker section. For additional information regarding the linker, please see: https://angular.dev/tools/libraries/creating-libraries#consuming-partial-ivy-code-outside-the-angular-cli\n\n## Usage\n\nIn your webpack config, add the following plugin and loader.\n\n```typescript\nimport { AngularWebpackPlugin } from '@ngtools/webpack';\n\nexports = {\n /* ... */\n module: {\n rules: [\n /* ... */\n {\n test: /\\.[jt]sx?$/,\n loader: '@ngtools/webpack',\n },\n ],\n },\n\n plugins: [\n new AngularWebpackPlugin({\n tsconfig: 'path/to/tsconfig.json',\n // ... other options as needed\n }),\n ],\n};\n```\n\nThe loader works with webpack plugin to compile the application's TypeScript. It is important to include both, and to not include any other TypeScript loader.\n\n## Options\n\n- `tsconfig` [default: `tsconfig.json`] - The path to the application's TypeScript Configuration file. In the `tsconfig.json`, you can pass options to the Angular Compiler with `angularCompilerOptions`. Relative paths will be resolved from the Webpack compilation's context.\n- `compilerOptions` [default: none] - Overrides options in the application's TypeScript Configuration file (`tsconfig.json`).\n- `jitMode` [default: `false`] - Enables JIT compilation and do not refactor the code to bootstrap. This replaces `templateUrl: \"string\"` with `template: require(\"string\")` (and similar for styles) to allow for webpack to properly link the resources.\n- `directTemplateLoading` [default: `true`] - Causes the plugin to load component templates (HTML) directly from the filesystem. This is more efficient if only using the `raw-loader` to load component templates. Do not enable this option if additional loaders are configured for component templates.\n- `fileReplacements` [default: none] - Allows replacing TypeScript files with other TypeScript files in the build. This option acts on fully resolved file paths.\n- `inlineStyleFileExtension` [default: none] - When set inline component styles will be processed by Webpack as files with the provided extension.\n\n## Ivy Linker\n\nThe Ivy linker can be setup by using the Webpack `babel-loader` package.\nIf not already installed, add the `babel-loader` package using your project's package manager.\nThen in your webpack config, add the `babel-loader` with the following configuration.\nIf the `babel-loader` is already present in your configuration, the linker plugin can be added to\nthe existing loader configuration as well.\nEnabling caching for the `babel-loader` is recommended to avoid reprocessing libraries on\nevery build.\nFor additional information regarding the `babel-loader` package, please see: https://github.com/babel/babel-loader/tree/main#readme\n\n```typescript\nimport linkerPlugin from '@angular/compiler-cli/linker/babel';\n\nexports = {\n /* ... */\n module: {\n rules: [\n /* ... */\n {\n test: /\\.[cm]?js$/,\n use: {\n loader: 'babel-loader',\n options: {\n cacheDirectory: true,\n compact: false,\n plugins: [linkerPlugin],\n },\n },\n },\n ],\n },\n};\n```\n","packages/schematics/angular/README.md":"# @schematics/angular\n\nThis package contains a collection of [schematics](/packages/angular_devkit/schematics/README.md)\nfor generating an Angular application.\n\n## Schematics\n\n| Name | Description |\n| -------------- | ----------------------------------------------------------------------------------------------------- |\n| app-shell | Generates an app shell for running a server-side version of an app |\n| application | Generates a new basic app definition in the \"projects\" subfolder of the workspace |\n| class | Creates a new, generic class definition in the given project |\n| component | Creates a new, generic component definition in the given project |\n| directive | Creates a new, generic directive definition in the given project |\n| enum | Generates a new, generic enum definition in the given project |\n| guard | Generates a new, generic route guard definition in the given project |\n| interceptor | Creates a new, generic interceptor definition in the given project |\n| interface | Creates a new, generic interface definition in the given project |\n| library | Creates a new, generic library project in the current workspace |\n| module | Creates a new, generic NgModule definition in the given project |\n| ng-new | Creates a new project by combining the workspace and application schematics |\n| pipe | Creates a new, generic pipe definition in the given project |\n| resolver | Creates a new, generic resolver definition in the given project |\n| service | Creates a new, generic service definition in the given project |\n| service-worker | Pass this schematic to the \"run\" command to create a service worker |\n| web-worker | Creates a new, generic web worker definition in the given project |\n| workspace | Initializes an empty workspace and adds the necessary dependencies required by an Angular application |\n\n## Disclaimer\n\nWhile the schematics when executed via the Angular CLI and their associated options are considered stable, the programmatic APIs are not considered officially supported and are not subject to the breaking change guarantees of SemVer.\n","tests/schematics/update/packages/README.md":"\n## Update Package Group packages\n\n* `update-package-group-1@1.0.0` -> `update-package-group2@^1`\n* `update-package-group-2@1.0.0` -> `update-package-group1@1.0.0`\n----\n\n* `update-package-group-1@1.0.0` -> `update-package-group2@^1`\n* `update-package-group-2@1.1.0` -> `update-package-group1@1.0.0`\n----\n\n* `update-package-group-1@1.2.0` -> `update-package-group2@^2`\n* `update-package-group-2@2.0.0` -> `update-package-group1@^1`\n----\n"},"files":{"AGENTS.md":"---\ntrigger: always_on\n---\n\nThis is the source code for the Angular CLI and related build tooling. This guide outlines standard practices for AI agents working in this repository.\n\n## Environment\n\n- Use `pnpm` for package management.\n- Use `pnpm bazel test //target` to run tests.\n\n## Key Documentation\n\n- [Developer Guide](docs/DEVELOPER.md): definitive guide for building, debugging, and running test targets.\n- [Contributing Guide](CONTRIBUTING.md): general contribution workflows and guidelines.\n- [Commit Guidelines](CONTRIBUTING.md#commit): format for commit messages and PR titles.\n\n## Building\n\n- Make a local build of all packages:\n ```shell\n pnpm build --local\n ```\n\n## Coding Practices\n\n- **Imports:**\n - Always use the `node:` protocol for Node.js built-in imports (e.g., `node:fs`, `node:path`, `node:assert`).\n - Prefer named imports (e.g., `import { mkdtemp } from 'node:fs'`) or default imports (`import fs from 'node:fs'`) instead of namespace imports (`import * as fs`).\n - Use type-only imports (`import type { ... }`) when importing types to avoid runtime side-effects.\n- **Classes:**\n - Prefer ECMAScript private fields (`#field`) over TypeScript `private` keywords for encapsulated state.\n\n## Testing\n\n- **Temporary Directories (`TEST_TMPDIR`):**\n - Tests in this repository only run in Bazel. **ALWAYS** use `process.env['TEST_TMPDIR']` and assert that it is set:\n ```ts\n import assert from 'node:assert';\n import { mkdtemp } from 'node:fs/promises';\n import { join } from 'node:path';\n\n describe('...', () => {\n let tempRoot: string;\n\n beforeAll(async () => {\n const baseTmpDir = process.env['TEST_TMPDIR'];\n assert(baseTmpDir, 'TEST_TMPDIR is not set');\n tempRoot = await mkdtemp(join(baseTmpDir, 'angular-cli-test-'));\n });\n });\n ```\n - **NEVER** use or fallback to `os.tmpdir()`. Bazel executes tests in hermetic sandboxes and sets `TEST_TMPDIR` to an isolated, sandboxed directory. Using `os.tmpdir()` can cause sandboxing failures, permission errors, or file leakage outside the Bazel sandbox.\n- **Unit & Integration Tests:**\n - Run all unit and integration tests: `pnpm bazel test //packages/...`\n - Run a specific unit test target (e.g., `pnpm bazel test //packages/angular/build:test`). Note that package `:test` targets may exclude builder integration tests (such as specs under `**/builders/**/tests/**`).\n - Run a specific builder integration test target (e.g., `pnpm bazel test //packages/angular/build:library_integration_tests` or `pnpm bazel test //packages/angular/build:application_integration_tests`).\n - Query all test targets: `pnpm bazel query \"tests(//packages/...)\"`\n - Find the exact test target for a specific spec file (using its workspace-relative path, which Bazel resolves as a source file target): `pnpm bazel query \"kind(jasmine_test, rdeps(//packages/..., ))\"`\n - Focus specific tests when debugging: use `fdescribe()` and `fit()`. NEVER commit focused tests to the repository.\n - Run tests without sharding when isolating or debugging: use `--config=no-sharding` with a specific test target (e.g., `pnpm bazel test //packages/angular/build:library_integration_tests --config=no-sharding`).\n This disables test sharding (`--test_sharding_strategy=disabled`) and flaky test retries (`--flaky_test_attempts=1`).\n This is especially useful when isolating test runs or debugging with focused tests (`fit`/`fdescribe`) to avoid empty shard failures and unnecessary re-runs.\n Do not use this flag when running broad test suites (such as `//packages/...`), as executing tests without sharding takes significantly longer.\n- **End-to-End Tests:**\n - Run subset of E2E tests: `pnpm bazel test //tests:e2e_node22 --config=e2e --test_filter=\"\"`\n\n## Pull Requests\n\n- Use the `gh` CLI (GitHub CLI) for creating and managing pull requests.\n- **Fixup Commits:**\n - When addressing review feedback, **ALWAYS** use fixup commits (`git commit --fixup `) instead of amending existing commits. This preserves commit history during review and allows reviewers to easily see incremental changes.\n - Only use fixup commits for changes that directly belong to the target commit. Unrelated changes must be made in a separate commit with their own commit message, not as a fixup commit.\n - Fixup commits are automatically squashed when merging with `pnpm ng-dev pr merge` or optionally when rebasing with `pnpm ng-dev pr rebase `.\n- Use `pnpm ng-dev pr` commands:\n - `pnpm ng-dev pr rebase `: Rebase a PR branch on its target branch and optionally squash fixup commits.\n - `pnpm ng-dev pr merge `: Merge an approved PR into its targeted branches.\n","packages/README.md":"# `/packages` Folder\n\nThis folder is the root of all defined packages in this repository.\n\nPackages that are marked as `private: true` will not be published to NPM.\n\nThis folder includes a directory for every scope in NPM, without the `@` sign. Then one folder\nper package, which contains the `package.json`.\n","packages/angular/cli/README.md":"# Angular CLI - The CLI tool for Angular.\n\nThe sources for this package are in the [Angular CLI](https://github.com/angular/angular-cli) repository. Please file issues and pull requests against that repository.\n\nUsage information and reference details can be found in repository [README](https://github.com/angular/angular-cli/blob/main/README.md) file.\n","packages/angular/create/README.md":"# `@angular/create`\n\n## Create an Angular CLI workspace\n\nScaffold an Angular CLI workspace without needing to install the Angular CLI globally. All of the [ng new](https://angular.dev/cli/new) options and features are supported.\n\n## Usage\n\n### npm\n\n```\nnpm init @angular@latest [project-name] -- [...options]\n```\n\n### yarn\n\n```\nyarn create @angular [project-name] [...options]\n```\n\n### pnpm\n\n```\npnpm create @angular [project-name] [...options]\n```\n\n### bun\n\n```\nbun create @angular [project-name] [...options]\n```\n","packages/angular/pwa/README.md":"# `@angular/pwa`\n\nThis is a [schematic](https://angular.dev/tools/cli/schematics) for adding\n[Progressive Web App](https://web.dev/progressive-web-apps/) support to an Angular project. Run the\nschematic with the [Angular CLI](https://angular.dev/tools/cli):\n\n```shell\nng add @angular/pwa --project \n```\n\nExecuting the command mentioned above will perform the following actions:\n\n1. Adds [`@angular/service-worker`](https://npmjs.com/@angular/service-worker) as a dependency to your project.\n1. Enables service worker builds in the Angular CLI.\n1. Imports and registers the service worker in the application module.\n1. Updates the `index.html` file to inlclude a link to add the [manifest.webmanifest](https://developer.mozilla.org/en-US/docs/Web/Manifest) file.\n1. Installs icon files to support the installed Progressive Web App (PWA).\n1. Creates the service worker configuration file called `ngsw-config.json`, specifying caching behaviors and other settings.\n\nSee [Getting started with service workers](https://angular.dev/ecosystem/service-workers/getting-started)\nfor more information.\n","packages/angular/ssr/README.md":"# Angular SSR\n\nRead the dev guide [here](https://angular.dev/guide/ssr).\n","packages/angular_devkit/architect/README.md":"# Angular Build Facade\n\nWIP\n","packages/angular_devkit/architect/src/jobs/README.md":"# Description\n\nJobs is the Angular DevKit subsystem for scheduling and running generic functions with clearly\ntyped inputs and outputs. A `Job` instance is a function associated with metadata. You can\nschedule a job, synchronize it with other jobs, and use it to schedule other jobs.\n\nThe whole API is serializable, allowing you to use a Node Stream or message channel to\ncommunicate between the job and the job scheduler.\n\nJobs are lazy, cold, and guaranteed to execute exactly once when scheduled. Subscribing to a job\nreturns messages from the point where the job is at.\n\n## Argument, Input, Output and Channels\n\nA job receives a single argument when scheduled and can also listen to an input channel. It can\nemit multiple outputs, and can also provide multiple output channels that emit asynchronous JSON\nmessages, which can be typed.\n\nThe I/O model is like that of an executable, where the argument corresponds to arguments on the\ncommand line, the input channel to STDIN, the output channel to STDOUT, and the channels\nwould be additional output streams.\n\n## LifeCycle\n\nA `Job` goes through multiple LifeCycle messages before its completion;\n\n1. `JobState.Queued`. The job was queued and is waiting. This is the default state from the\n scheduler.\n1. `JobState.Ready`. The job's dependencies (see\n [\"Synchronizing and Dependencies\"](#Dependencies)) are done running, the argument is\n validated, and the job is ready to execute.\n1. `JobState.Started`. The argument has been validated, the job has been called and is running.\n This is handled by the job itself (or `createJobHandler()`).\n1. `JobState.Ended`. The job has ended and is done running. This is handled by the job itself (or\n `createJobHandler()`).\n1. `JobState.Errored`. A unrecoverable error happened.\n\nEach state (except `Queued`) corresponds to a `JobOutboundMessage` on the `outboundBus` observable\nthat triggers the state change. The `Scheduler` emits the `Ready` and `Errored` messages; the job\nimplementation should not emit them, and if it does they are filtered out. You can listen for\nthese messages or use the corresponding state member.\n\nThe job implementation should emit the `Start` and `End` messages when it is starting the job logic\nitself. Only the first `Start` and `End` messages will be forwarded. Any more will be filtered out.\n\nThe `Queued` state is set as the job is scheduled, so there is no need to listen for the message.\n\n## `Job` Object\n\nThe `Job` object that is returned when you schedule a job provides access to the job's status and\nutilities for tracking and modifying the job.\n\n1. `id`. A unique symbol that can be used as a Map key.\n1. `description`. The description of the job from the scheduler. See `JobDescription` object.\n1. `argument`. The argument value that was used to start the job.\n1. `input`. An `Observer` that can be used to send validated inputs to the job itself.\n1. `output`. An `Observable` that filters out messages to get only the returned output\n of a job.\n1. `promise`. A promise that waits for the last output of a job. Returns the last value outputted\n (or no value if there's no last value).\n1. `state`. The current state of the job (see `LifeCycle`).\n1. `channels`. A map of side channels the user can listen to as `Observable`.\n1. `ping()`. A function that can be used to ping the job, receiving a `Promise` for when the ping\n is answered.\n1. `stop()`. Sends a `stop` input to the job, which suggests to stop the job. The job itself can\n choose to ignore this message.\n1. `inboundBus`. The raw input `Observer`. This can be used to send messages to\n the `context.inboundBus` observable in the job. These are `JobInboundMessage` messages. See\n [\"Communicating With Jobs\"](#Communicating).\n1. `outboundBus`. The raw output `Observable`. This can be used to listen to messages\n from the job. See [\"Communicating With Jobs\"](#Communicating).\n\n## `JobHandlerContext` Object\n\nThe `JobHandlerContext<>` is passed to the job handler code in addition to its argument. The\ncontext contains the following members:\n\n1. `description`. The description of the job. Its name and schemas.\n1. `scheduler`. A `Scheduler<>` instance that can be used to create additional jobs.\n1. `dependencies`. A generic list of other job instances that were run as dependencies when\n scheduling this job. Their `id` is not guaranteed to match the `id` of the `Job<>` instance\n itself (those `Job<>`s might just be proxies). The state of those `Job<>` is guaranteed to be\n `JobState.Ended`, as `JobState.Errored` would have prevented this handler from running.\n1. `inboundBus`. The raw input observable, complement of the `inboundBus` observer from the `Job<>`.\n\n# Examples\n\nAn example of a job that adds all input together and return the output value. We use a\nsimple synchronous job registry and a simple job scheduler.\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\nconst add = jobs.createJobHandle((input) =>\n input.reduce((total, curr) => total + curr, 0),\n);\n\n// Register the job in a SimpleJobRegistry. Different registries have different API.\nconst registry = new jobs.SimpleJobRegistry();\nconst scheduler = new jobs.SimpleScheduler(registry);\nregistry.register(add, {\n name: 'add',\n input: { type: 'array', items: { type: 'number' } },\n output: { type: 'number' },\n});\n\nscheduler\n .schedule('add', [1, 2, 3, 4])\n .promise.then((output) => console.log('1 + 2 + 3 + 4 is ' + output));\n```\n\n# Creating Jobs\n\nA job is at its core a function with a description object attached to it. The description object\nstores the JSON schemas used to validate the types of the argument passed in, the input and\noutput values. By default, a job accepts and can output any JSON object.\n\n```typescript\nimport { Observable } from 'rxjs';\nimport { jobs } from '@angular-devkit/core';\n\nconst argument = {\n type: 'array',\n items: { type: 'number' },\n};\nconst output = {\n type: 'number',\n};\n\nexport function add(argument: number[]): Observable> {\n return new Observable((o) => {\n o.next({ kind: jobs.JobOutboundMessageKind.Start });\n o.next({\n kind: jobs.JobOutboundMessageKind.Output,\n output: argument.reduce((total, curr) => total + curr, 0),\n });\n o.next({ kind: jobs.JobOutboundMessageKind.End });\n o.complete();\n });\n}\n\n// Add a property to `add` to make it officially a JobHandler. The Job system does not recognize\n// any function as a JobHandler.\nadd.jobDescription = {\n argument: argument,\n output: output,\n};\n\n// Call the job with an array as argument, and log its output.\ndeclare const scheduler: jobs.Scheduler;\nscheduler.schedule('add', [1, 2, 3, 4]).output.subscribe((x) => console.log(x)); // Will output 10.\n```\n\nThis is a lot of boilerplate, so we made some helpers to improve readability and manage argument,\ninput and output automatically:\n\n```typescript\n// Add is a JobHandler function, like the above.\nexport const add = jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n);\n\n// Schedule like above.\n```\n\nYou can also return a Promise or an Observable, as jobs are asynchronous. This helper will set\nstart and end messages appropriately. It will also manage channels automatically (see below).\n\nA more complex job can be declared like this:\n\n```typescript\nimport { Observable } from 'rxjs';\nimport { jobs } from '@angular-devkit/core';\n\n// Show progress with each count in a separate output channel. Output \"more\" in a channel.\nexport const count = jobs.createJobHandler(\n // Receive a context that contains additional methods to create channels.\n (argument: number, { createChannel }) =>\n new Observable((o) => {\n const side = createChannel('side', { type: 'string', const: 'more' });\n const progress = createChannel('progress', { type: 'number' });\n let i = 0;\n function doCount() {\n o.next(i++);\n progress.next(i / argument);\n side.next('more');\n\n if (i < argument) {\n setTimeout(doCount, 100);\n } else {\n o.complete();\n }\n }\n setTimeout(doCount, 100);\n }),\n {\n argument: { type: 'number' },\n output: { type: 'number' },\n },\n);\n\n// Get a hold of a scheduler that refers to the job above.\ndeclare const scheduler: jobs.Scheduler;\n\nconst job = scheduler.schedule('count', 0);\njob.getChannel('side').subscribe((x) => console.log(x));\n// You can type a channel too. Messages will be filtered out.\njob.getChannel('progress', { type: 'number' }).subscribe((x) => console.log(x));\n```\n\n## Communicating With Jobs\n\nJobs can be started and updated in a separate process or thread, and as such communication with a\njob should avoid using global objects (which might not be shared). The jobs API and schedulers\nprovide 2 communication streams (one for input and the other for output), named `inboundBus` and\n`outboundBus`.\n\n### Raw Input Stream\n\nThe `schedule()` function returns a `Job<>` interface that contains a `inboundBus` member of type\n`Observer`. All messages sent _to_ the job goes through this stream. The `kind`\nmember of the `JobInboundMessage` interface dictates what kind of message it is sending:\n\n1. `JobInboundMessageKind.Ping`. A simple message that should be answered with\n `JobOutboundMessageKind.Pong` when the job is responsive. The `id` field of the message should\n be used when returning `Pong`.\n1. `JobInboundMessageKind.Stop`. The job should be stopped. This is used when\n cancelling/unsubscribing from the `output` (or by calling `stop()`). Any inputs or outputs\n after this message will be ignored.\n1. `JobInboundMessageKind.Input` is used when sending inputs to a job. These correspond to the\n `next` methods of an `Observer` and are reported to the job through its `context.input`\n Observable. There is no way to communicate an error to the job.\n\nUsing the `createJobHandler()` helper, all those messages are automatically handled by the\nboilerplate code. If you need direct access to raw inputs, you should subscribe to the\n`context.inboundBus` Observable.\n\n### Raw Output Stream\n\nThe `Job<>` interface also contains a `outboundBus` member (of type\n`Observable>` where `O` is the typed output of the job) which is the output\ncomplement of `inboundBus`. All messages sent _from_ the job goes through this stream. The `kind`\nmember of the `JobOutboundMessage` interface dictates what kind of message it is sending:\n\n1. `JobOutboundMessageKind.Create`. The `Job<>` was created, its dependencies are done, and the\n library is validating Argument and calling the internal job code.\n1. `JobOutboundMessageKind.Start`. The job code itself should send that message when started.\n `createJobHandler()` will do it automatically.\n1. `JobOutboundMessageKind.End`. The job has ended. This is done by the job itself and should always\n be sent when completed. The scheduler will listen to this message to set the state and unblock\n dependent jobs. `createJobHandler()` automatically send this message.\n1. `JobOutboundMessageKind.Pong`. The job should answer a `JobInboundMessageKind.Ping` message with\n this. Automatically done by `createJobHandler()`.\n1. `JobOutboundMessageKind.Output`. An `Output` has been generated by the job.\n1. `JobOutboundMessageKind.ChannelMessage`, `JobOutboundMessageKind.ChannelError` and\n `JobOutboundMessageKind.ChannelComplete` are used for output channels. These correspond to the\n `next`, `error` and `complete` methods of an `Observer` and are available to the callee through\n the `job.channels` map of Observable.\n\nThose messages can be accessed directly through the `job.outboundBus` member. The job itself should\nreturn an `Observable>`. The `createJobHandler()` helper handles most of use\ncases of this and makes it easier for jobs to handle this.\n\n## Job Dispatchers\n\nDispatchers are a helper that redirect to different jobs given conditions. To create a job\ndispatcher, use the `createDispatcher()` function:\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\n// A dispatcher that installs node modules given a user's preference.\nconst dispatcher = jobs.createDispatcher({\n name: 'node-install',\n argument: { properties: { moduleName: { type: 'string' } } },\n output: { type: 'boolean' },\n});\n\nconst npmInstall = jobs.createJobHandler(/* ... */, { name: 'npm-install' });\nconst yarnInstall = jobs.createJobHandler(/* ... */, { name: 'yarn-install' });\nconst pnpmInstall = jobs.createJobHandler(/* ... */, { name: 'pnpm-install' });\n\ndeclare const registry: jobs.SimpleJobRegistry;\nregistry.register(dispatcher);\nregistry.register(npmInstall);\nregistry.register(yarnInstall);\nregistry.register(pnpmInstall);\n\n// Default to npm.\ndispatcher.setDefaultDelegate(npmInstall.name);\n// If the user is asking for yarn over npm, uses it.\ndispatcher.addConditionalDelegate(() => userWantsYarn, yarnInstall.name);\n```\n\n## Execution Strategy\n\nJobs are always run in parallel and will always start, but many helper functions are provided\nwhen creating a job to help you control the execution strategy;\n\n1. `serialize()`. Multiple runs of this job will be queued with each others.\n1. `memoize(replayMessages = false)` will create a job, or reuse the same job when inputs are\n matching. If the inputs don't match, a new job will be started and its outputs will be stored.\n\nThese strategies can be used when creating the job:\n\n```typescript\n// Same input and output as above.\n\nexport const add = jobs.strategy.memoize()(\n jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n ),\n);\n```\n\nStrategies can be reused to synchronize between jobs. For example, given jobs `jobA` and `jobB`,\nyou can reuse the strategy to serialize both jobs together;\n\n```typescript\nconst strategy = jobs.strategy.serialize();\nconst jobA = strategy(jobs.createJobHandler(...));\nconst jobB = strategy(jobs.createJobHandler(...));\n```\n\nEven further, we can have package A and package B run in serialization, and B and C also be\nserialized. Running A and C will run in parallel, while running B will wait for both A and C\nto finish.\n\n```typescript\nconst strategy1 = jobs.strategy.serialize();\nconst strategy2 = jobs.strategy.serialize();\nconst jobA = strategy1(jobs.createJobHandler(...));\nconst jobB = strategy1(strategy2(jobs.createJobHandler(...)));\nconst jobC = strategy2(jobs.createJobHandler(...));\n```\n\n# Scheduling Jobs\n\nJobs can be scheduled using a `Scheduler` interface, which contains a `schedule()` method:\n\n```typescript\ninterface Scheduler {\n /**\n * Schedule a job to be run, using its name.\n * @param name The name of job to be run.\n * @param argument The argument to send to the job when starting it.\n * @param options Scheduling options.\n * @returns The Job being run.\n */\n schedule(\n name: JobName,\n argument: I,\n options?: ScheduleJobOptions,\n ): Job;\n}\n```\n\nThe scheduler also has a `getDescription()` method to get a `JobDescription` object for a certain\nname; that description contains schemas for the argument, input, output, and other channels:\n\n```typescript\ninterface Scheduler {\n /**\n * Get a job description for a named job.\n *\n * @param name The name of the job.\n * @returns A description, or null if the job cannot be scheduled.\n */\n getDescription(name: JobName): JobDescription | null;\n\n /**\n * Returns true if the job name has been registered.\n * @param name The name of the job.\n * @returns True if the job exists, false otherwise.\n */\n has(name: JobName): boolean;\n}\n```\n\nFinally, the scheduler interface has a `pause()` method to stop scheduling. This will queue all\njobs and wait for the unpause function to be called before unblocking all the jobs scheduled.\nThis does not affect already running jobs.\n\n```typescript\ninterface Scheduler {\n /**\n * Pause the scheduler, temporary queueing _new_ jobs. Returns a resume function that should be\n * used to resume execution. If multiple `pause()` were called, all their resume functions must\n * be called before the Scheduler actually starts new jobs. Additional calls to the same resume\n * function will have no effect.\n *\n * Jobs already running are NOT paused. This is pausing the scheduler only.\n *\n * @returns A function that can be run to resume the scheduler. If multiple `pause()` calls\n * were made, all their return function must be called (in any order) before the\n * scheduler can resume.\n */\n pause(): () => void;\n}\n```\n\n## Synchronizing and Dependencies\n\nWhen scheduling jobs, it is often necessary to run jobs after certain other jobs are finished.\nThis is done through the `dependencies` options in the `schedule()` method.\n\nThese jobs will also be passed to the job being scheduled, through its context. This can be\nuseful if, for example, the output of those jobs are of a known type, or have known side channels.\n\nAn example of this would be a compiler that needs to know the output directory of other compilers\nbefore it, in a tool chain.\n\n### Dependencies\n\nWhen scheduling jobs, the user can add a `dependencies` field to the scheduling options. The\nscheduler will wait for those dependencies to finish before running the job, and pass those jobs\nin the context of the job.\n\n### Accessing Dependencies\n\nJobs are called with a `JobHandlerContext` as a second argument, which contains a\n`dependencies: Job[]` member which contains all dependencies that were used when\nscheduling the job. Those aren't fully typed as they are determined by the user, and not the job\nitself. They also can contain jobs that are not finished, and the job should use the `state`\nmember of the job itself before trying to access its content.\n\n### Scheduler Sub Jobs\n\nThe `JobHandlerContext` also contains a `scheduler` member which can be used to schedule jobs\nusing the same scheduler that was used for the job. This allows jobs to call other jobs\nand wait for them to end.\n\n## Available Schedulers\n\nThe Core Angular DevKit library provides 2 implementations for the `Scheduler` interface:\n\n## SimpleJobRegistry\n\nAvailable in the jobs namespace. A registry that accept job registration, and can also schedule\njobs.\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\nconst add = jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n);\n\n// Register the job in a SimpleJobRegistry. Different registries have different API.\nconst registry = new jobs.SimpleJobRegistry();\nconst scheduler = new SimpleJobScheduler(registry);\n\nregistry.register(add, {\n name: 'add',\n argument: { type: 'array', items: { type: 'number' } },\n output: { type: 'number' },\n});\n\nscheduler.schedule('add', [1, 2, 3, 4]);\n```\n\n## NodeModuleJobRegistry\n\nAvailable through `@angular-devkit/core/node`.\n\nA scheduler that loads jobs using their node package names. These jobs need to use the\n`createJobHandler()` helper and report their argument/input/output schemas that way.\n\n```typescript\ndeclare const registry: NodeModuleJobRegistry;\nconst scheduler = new SimpleJobScheduler(registry);\n\nscheduler.schedule('some-node-package#someExport', 'input');\n```\n\n# Gotchas\n\n1. Deadlocking Dependencies \n It is impossible to add dependencies to an already running job, but it is entirely possible to\n get locked between jobs. Be aware of your own dependencies.\n\n1. Using `job.promise` \n `job.promise` waits for the job to ends. Don't rely on it unless you know the job is not\n watching and running for a long time. If you aren't sure, use\n `job.output.pipe(first()).toPromise()` instead which will return the first next output,\n regardless of whether the job watches and rerun or not.\n\n# FAQ\n\n1. Laziness \n A job is lazy until executed, but its messages will be replayed when resubscribed.\n\n1. Serialize Strategy vs Dependencies \n Strategies are functions that transform the execution of a job, and can be used when\n declaring the job, or registering it. Dependencies, on the other hand, are listed when\n scheduling a job to order jobs during scheduling.\n\n A job has no control over the way it's scheduled, and its dependencies. It can, however,\n declare that it shouldn't run at the same time as itself. Alternatively, a user could\n schedule a job twice and imply that the second run should wait for the first to finish. In\n practice, this would be equivalent to having the job be serialized, but the important detail\n is in _whom_ is defining the rules; using the `serialize()` strategy, the job implementation\n is, while when using dependencies, the user is.\n\n The user does not need to know how to job needs to synchronize with itself, and the job does\n not need to know how it synchronizes with other jobs that it doesn't know about. That's part\n of the strength of this system as every job can be developed in a vacuum, only caring about\n its contracts (argument, input and output) and its own synchronization.\n","packages/angular_devkit/build_angular/README.md":"# @angular-devkit/build-angular\n\nThis package contains [Architect builders](/packages/angular_devkit/architect/README.md) used to build and test Angular applications and libraries.\n\n## Builders\n\n| Name | Description |\n| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| application | Build an Angular application targeting a browser and server environment using [esbuild](https://esbuild.github.io). |\n| app-shell | Build an Angular [App shell](https://angular.dev/ecosystem/service-workers/app-shell). |\n| browser | Build an Angular application targeting a browser environment using [Webpack](https://webpack.js.org). |\n| browser-esbuild | Build an Angular application targeting a browser environment using [esbuild](https://esbuild.github.io). |\n| dev-server | A development server that provides live reloading. |\n| extract-i18n | Extract i18n messages from an Angular application. |\n| karma | Execute unit tests using [Karma](https://github.com/karma-runner/karma) test runner. |\n| ng-packagr | Build and package an Angular library in [Angular Package Format (APF)](https://angular.dev/tools/libraries/angular-package-format) format using [ng-packagr](https://github.com/ng-packagr/ng-packagr). |\n| prerender | [Prerender](https://angular.dev/guide/prerendering) pages of your application. Prerendering is the process where a dynamic page is processed at build time generating static HTML. |\n| server | Build an Angular application targeting a [Node.js](https://nodejs.org) environment. |\n| ssr-dev-server | A development server which offers live reload during development, but uses server-side rendering. |\n\n## Disclaimer\n\nWhile the builders when executed via the Angular CLI and their associated options are considered stable, the programmatic APIs are not considered officially supported and are not subject to the breaking change guarantees of SemVer.\n","packages/angular_devkit/build_webpack/README.md":"# Webpack Builder for Architect\n\nThis package allows you to run Webpack and Webpack Dev Server using Architect.\n\nTo use it on your Angular CLI app, follow these steps:\n\n- run `npm install @angular-devkit/build-webpack`.\n- create a webpack configuration.\n- add the following targets inside `angular.json`.\n\n```\n \"projects\": {\n \"app\": {\n // ...\n \"architect\": {\n // ...\n \"build-webpack\": {\n \"builder\": \"@angular-devkit/build-webpack:webpack\",\n \"options\": {\n \"webpackConfig\": \"webpack.config.js\"\n }\n },\n \"serve-webpack\": {\n \"builder\": \"@angular-devkit/build-webpack:webpack-dev-server\",\n \"options\": {\n \"webpackConfig\": \"webpack.config.js\"\n }\n }\n }\n```\n\n- run `ng run app:build-webpack` to build, and `ng run app:serve-webpack` to serve.\n\nAll options, including `watch` and `stats`, are looked up inside the webpack configuration.\n","packages/angular_devkit/core/README.md":"# Core\n\n> Shared utilities for Angular DevKit.\n\n# Exception\n\n# Json\n\n## Schema\n\n### SchemaValidatorResult\n\n```\nexport interface SchemaValidatorResult {\n success: boolean;\n errors?: string[];\n}\n```\n\n### SchemaValidator\n\n```\nexport interface SchemaValidator {\n (data: any): Observable;\n}\n```\n\n### SchemaFormatter\n\n```\nexport interface SchemaFormatter {\n readonly async: boolean;\n validate(data: any): boolean | Observable;\n}\n```\n\n### SchemaRegistry\n\n```\nexport interface SchemaRegistry {\n compile(schema: Object): Observable;\n addFormat(name: string, formatter: SchemaFormatter): void;\n}\n```\n\n### CoreSchemaRegistry\n\n`SchemaRegistry` implementation using https://github.com/epoberezkin/ajv.\nConstructor accepts object containing `SchemaFormatter` that will be added automatically.\n\n```\nexport class CoreSchemaRegistry implements SchemaRegistry {\n constructor(formats: { [name: string]: SchemaFormatter} = {}) {}\n}\n```\n\n# Logger\n\n# Utils\n\n# Virtual FS\n\n# Workspaces\n\nThe `workspaces` namespace provides an API for interacting with the workspace file formats.\nIt provides an abstraction of the underlying storage format of the workspace and provides\nsupport for both reading and writing. Currently, the only supported format is the JSON-based\nformat used by the Angular CLI. For this format, the API provides internal change tracking of values which\nenables fine-grained updates to the underlying storage of the workspace. This allows for the\nretention of existing formatting and comments.\n\nA workspace is defined via the following object model. Definition collection objects are specialized\nJavascript `Map` objects with an additional `add` method to simplify addition and provide more localized\nerror checking of the newly added values.\n\n```ts\nexport interface WorkspaceDefinition {\n readonly extensions: Record;\n readonly projects: ProjectDefinitionCollection;\n}\n\nexport interface ProjectDefinition {\n readonly extensions: Record;\n readonly targets: TargetDefinitionCollection;\n root: string;\n prefix?: string;\n sourceRoot?: string;\n}\n\nexport interface TargetDefinition {\n options?: Record;\n configurations?: Record | undefined>;\n builder: string;\n}\n```\n\nThe API is asynchronous and has two main functions to facilitate reading, creation, and modifying\na workspace: `readWorkspace` and `writeWorkspace`.\n\n```ts\nexport enum WorkspaceFormat {\n JSON,\n}\n```\n\n```ts\nexport function readWorkspace(\n path: string,\n host: WorkspaceHost,\n format?: WorkspaceFormat,\n): Promise<{ workspace: WorkspaceDefinition }>;\n```\n\n```ts\nexport function writeWorkspace(\n workspace: WorkspaceDefinition,\n host: WorkspaceHost,\n path?: string,\n format?: WorkspaceFormat,\n): Promise;\n```\n\nA `WorkspaceHost` abstracts the underlying data access methods from the functions. It provides\nmethods to read, write, and analyze paths. A utility function is provided to create\nan instance of a `WorkspaceHost` from the Angular DevKit's virtual filesystem host abstraction.\n\n```ts\nexport interface WorkspaceHost {\n readFile(path: string): Promise;\n writeFile(path: string, data: string): Promise;\n isDirectory(path: string): Promise;\n isFile(path: string): Promise;\n}\n\nexport function createWorkspaceHost(host: virtualFs.Host): WorkspaceHost;\n```\n\n## Usage Example\n\nTo demonstrate the usage of the API, the following code will show how to add a option property\nto a build target for an application.\n\n```ts\nimport { NodeJsSyncHost } from '@angular-devkit/core/node';\nimport { workspaces } from '@angular-devkit/core';\n\nasync function demonstrate() {\n const host = workspaces.createWorkspaceHost(new NodeJsSyncHost());\n const { workspace } = await workspaces.readWorkspace('path/to/workspace/directory/', host);\n\n const project = workspace.projects.get('my-app');\n if (!project) {\n throw new Error('my-app does not exist');\n }\n\n const buildTarget = project.targets.get('build');\n if (!buildTarget) {\n throw new Error('build target does not exist');\n }\n\n buildTarget.options.optimization = true;\n\n await workspaces.writeWorkspace(workspace, host);\n}\n\ndemonstrate();\n```\n","packages/angular_devkit/schematics/README.md":"# Schematics\n\n> A scaffolding library for the modern web.\n\n## Description\n\nSchematics are generators that transform an existing filesystem. They can create files, refactor existing files, or move files around.\n\nWhat distinguishes Schematics from other generators, such as Yeoman or Yarn Create, is that schematics are purely descriptive; no changes are applied to the actual filesystem until everything is ready to be committed. There is no side effect, by design, in Schematics.\n\n# Glossary\n\n| Term | Description |\n| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Schematics** | A generator that executes descriptive code without side effects on an existing file system. |\n| **Collection** | A list of schematics metadata. Schematics can be referred by name inside a collection. |\n| **Tool** | The code using the Schematics library. |\n| **Tree** | A staging area for changes, containing the original file system, and a list of changes to apply to it. |\n| **Rule** | A function that applies actions to a `Tree`. It returns a new `Tree` that will contain all transformations to be applied. |\n| **Source** | A function that creates an entirely new `Tree` from an empty filesystem. For example, a file source could read files from disk and create a Create Action for each of those. |\n| **Action** | An atomic operation to be validated and committed to a filesystem or a `Tree`. Actions are created by schematics. |\n| **Sink** | The final destination of all `Action`s. |\n| **Task** | A Task is a way to execute an external command or script in a schematic. A Task can be used to perform actions such as installing dependencies, running tests, or building a project. A Task is created by using the `SchematicContext` object and can be scheduled to run before or after the schematic `Tree` is applied. |\n\n# Tooling\n\nSchematics is a library, and does not work by itself. A [reference CLI](https://github.com/angular/angular-cli/blob/main/packages/angular_devkit/schematics_cli/bin/schematics.ts) is available on this repository, and is published on NPM at [@angular-devkit/schematics-cli](https://www.npmjs.com/package/@angular-devkit/schematics-cli). This document explains the library usage and the tooling API, but does not go into the tool implementation itself.\n\nThe tooling is responsible for the following tasks:\n\n1. Create the Schematic Engine, and pass in a Collection and Schematic loader.\n1. Understand and respect the Schematics metadata and dependencies between collections. Schematics can refer to dependencies, and it's the responsibility of the tool to honor those dependencies. The reference CLI uses NPM packages for its collections.\n1. Create the Options object. Options can be anything, but the schematics can specify a JSON Schema that should be respected. The reference CLI, for example, parses the arguments as a JSON object and validates it with the Schema specified by the collection.\n1. Schematics provides some JSON Schema formats for validation that tooling should add. These validate paths, html selectors and app names. Please check the reference CLI for how these can be added.\n1. Call the schematics with the original Tree. The tree should represent the initial state of the filesystem. The reference CLI uses the current directory for this.\n1. Create a Sink and commit the result of the schematics to the Sink. Many sinks are provided by the library; FileSystemSink and DryRunSink are examples.\n1. Output any logs propagated by the library, including debugging information.\n\nThe tooling API is composed of the following pieces:\n\n## Engine\n\nThe `SchematicEngine` is responsible for loading and constructing `Collection`s and `Schematics`. When creating an engine, the tooling provides an `EngineHost` interface that understands how to create a `CollectionDescription` from a name, and how to create a `SchematicDescription`.\n\n# Schematics (Generators)\n\nSchematics are generators and part of a `Collection`.\n\n## Collection\n\nA Collection is defined by a `collection.json` file (in the reference CLI). This JSON defines the following properties:\n\n| Prop Name | Type | Description |\n| ----------- | -------- | --------------------------- |\n| **name** | `string` | The name of the collection. |\n| **version** | `string` | Unused field. |\n\n## Schematic\n\n# Operators, Sources and Rules\n\nA `Source` is a generator of a `Tree`; it creates an entirely new root tree from nothing. A `Rule` is a transformation from one `Tree` to another. A `Schematic` (at the root) is a `Rule` that is normally applied on the filesystem.\n\n## Operators\n\n`FileOperator`s apply changes to a single `FileEntry` and return a new `FileEntry`. The result follows these rules:\n\n1. If the `FileEntry` returned is null, a `DeleteAction` will be added to the action list.\n1. If the path changed, a `RenameAction` will be added to the action list.\n1. If the content changed, an `OverwriteAction` will be added to the action list.\n\nIt is impossible to create files using a `FileOperator`.\n\n## Provided Operators\n\nThe Schematics library provides multiple `Operator` factories by default that cover basic use cases:\n\n| FileOperator | Description |\n| -------------------------------- | -------------------------------------------------------------------- |\n| `contentTemplate(options: T)` | Apply a content template (see the [Templating](#templating) section) |\n| `pathTemplate(options: T)` | Apply a path template (see the [Templating](#templating) section) |\n\n## Provided Sources\n\nThe Schematics library additionally provides multiple `Source` factories by default:\n\n| Source | Description |\n| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |\n| `empty()` | Creates a source that returns an empty `Tree`. |\n| `source(tree: Tree)` | Creates a `Source` that returns the `Tree` passed in as argument. |\n| `url(url: string)` | Loads a list of files from the given URL and returns a `Tree` with the files as `CreateAction` applied to an empty `Tree`. |\n| `apply(source: Source, rules: Rule[])` | Apply a list of `Rule`s to a source, and return the resulting `Source`. |\n\n## Provided Rules\n\nThe schematics library also provides `Rule` factories by default:\n\n| Rule | Description |\n| ------------------------------------------- | -------------------------------------------------------------------------------------- |\n| `noop()` | Returns the input `Tree` as is. |\n| `chain(rules: Rule[])` | Returns a `Rule` that's the concatenation of other `Rule`s. |\n| `forEach(op: FileOperator)` | Returns a `Rule` that applies an operator to every file of the input `Tree`. |\n| `move(root: string)` | Moves all the files from the input to a subdirectory. |\n| `merge(other: Tree)` | Merge the input `Tree` with the other `Tree`. |\n| `contentTemplate(options: T)` | Apply a content template (see the Template section) to the entire `Tree`. |\n| `pathTemplate(options: T)` | Apply a path template (see the Template section) to the entire `Tree`. |\n| `template(options: T)` | Apply both path and content templates (see the Template section) to the entire `Tree`. |\n| `filter(predicate: FilePredicate)` | Returns the input `Tree` with files that do not pass the `FilePredicate`. |\n\n# Templating\n\nAs referenced above, some functions are based upon a file templating system, which consists of path and content templating.\n\nThe system operates on placeholders defined inside files or their paths as loaded in the `Tree` and fills these in as defined in the following, using values passed into the `Rule` which applies the templating (i.e. `template(options: T)`).\n\n## Path Templating\n\n| Placeholder | Description |\n| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- |\n| `__variable__` | Replaced with the value of `variable`. |\n| `__variable@function__` | Replaced with the result of the call `function(variable)`. Can be chained to the left (`__variable@function1@function2__ ` etc). |\n\n## Content Templating\n\n| Placeholder | Description |\n| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |\n| `<%= expression %>` | Replaced with the result of the call of the given expression. This only supports direct expressions, no structural (for/if/...) JavaScript. |\n| `<%- expression %>` | Same as above, but the value of the result will be escaped for HTML when inserted (i.e. replacing '<' with '\\<') |\n| `<% inline code %>` | Inserts the given code into the template structure, allowing to insert structural JavaScript. |\n| `<%# text %>` | A comment, which gets entirely dropped. |\n\n# Examples\n\n## Simple\n\nAn example of a simple Schematics which creates a \"hello world\" file, using an option to determine its path:\n\n```typescript\nimport { Tree } from '@angular-devkit/schematics';\n\nexport default function MySchematic(options: any) {\n return (tree: Tree) => {\n tree.create(options.path + '/hi', 'Hello world!');\n return tree;\n };\n}\n```\n\nA few things from this example:\n\n1. The function receives the list of options from the tooling.\n1. It returns a [`Rule`](src/engine/interface.ts#L73), which is a transformation from a `Tree` to another `Tree`.\n\n## Templating\n\nA simplified example of a Schematics which creates a file containing a new Class, using an option to determine its name:\n\n```typescript\n// files/__name@dasherize__.ts\n\nexport class <%= classify(name) %> {\n}\n```\n\n```typescript\n// index.ts\n\nimport { strings } from '@angular-devkit/core';\nimport {\n Rule,\n SchematicContext,\n SchematicsException,\n Tree,\n apply,\n branchAndMerge,\n mergeWith,\n template,\n url,\n} from '@angular-devkit/schematics';\nimport { Schema as ClassOptions } from './schema';\n\nexport default function (options: ClassOptions): Rule {\n return (tree: Tree, context: SchematicContext) => {\n if (!options.name) {\n throw new SchematicsException('Option (name) is required.');\n }\n\n const templateSource = apply(url('./files'), [\n template({\n ...strings,\n ...options,\n }),\n ]);\n\n return branchAndMerge(mergeWith(templateSource));\n };\n}\n```\n\nAdditional things from this example:\n\n1. `strings` provides the used `dasherize` and `classify` functions, among others.\n1. The files are on-disk in the same root directory as the `index.ts` and loaded into a `Tree`.\n1. Then the `template` `Rule` fills in the specified templating placeholders. For this, it only knows about the variables and functions passed to it via the options-object.\n1. Finally, the resulting `Tree`, containing the new file, is merged with the existing files of the project which the Schematic is run on.\n","packages/angular_devkit/schematics_cli/README.md":"# Schematics CLI\n\nThis package contains the executable for running a [Schematic](/packages/angular_devkit/schematics/README.md).\n\n# Usage\n\n```\n$ schematics [CollectionName:]SchematicName [options, ...]\n\nBy default, if the collection name is not specified, use the internal collection provided\nby the Schematics CLI.\n\nOptions:\n --debug Debug mode. This is true by default if the collection is a relative\n path (in that case, turn off with --debug=false).\n\n --allow-private Allow private schematics to be run from the command line. Default to\n false.\n\n --dry-run Do not output anything, but instead just show what actions would be\n performed. Default to true if debug is also true.\n\n --force Force overwriting files that would otherwise be an error.\n\n --list-schematics List all schematics from the collection, by name. A collection name\n should be suffixed by a colon. Example: '@angular-devkit/schematics-cli:'.\n\n --no-interactive Disables interactive input prompts.\n\n --verbose Show more information.\n\n --help Show this message.\n\nAny additional option is passed to the Schematics depending on its schema.\n```\n\n# Examples\n\n1. Create a new NPM package that contains a blank schematic.\n\n```sh\n$ schematics blank \n```\n\n2. Walkthrough example that demonstrates how to build a schematic.\n\n```sh\n$ schematics schematic --name \n```\n","packages/angular_devkit/schematics_cli/blank/project-files/README.md":"# Getting Started With Schematics\n\nThis repository is a basic Schematic implementation that serves as a starting point to create and publish Schematics to NPM.\n\n### Testing\n\nTo test locally, install `@angular-devkit/schematics-cli` globally and use the `schematics` command line tool. That tool acts the same as the `generate` command of the Angular CLI, but also has a debug mode.\n\nCheck the documentation with\n\n```bash\nschematics --help\n```\n\n### Unit Testing\n\n`npm run test` will run the unit tests, using Jasmine as a runner and test framework.\n\n### Publishing\n\nTo publish, simply do:\n\n```bash\nnpm run build\nnpm publish\n```\n\nThat's it!\n","packages/angular_devkit/schematics_cli/schematic/files/README.md":"# Getting Started With Schematics\n\nThis repository is a basic Schematic implementation that serves as a starting point to create and publish Schematics to NPM.\n\n### Testing\n\nTo test locally, install `@angular-devkit/schematics-cli` globally and use the `schematics` command line tool. That tool acts the same as the `generate` command of the Angular CLI, but also has a debug mode.\n\nCheck the documentation with\n\n```bash\nschematics --help\n```\n\n### Unit Testing\n\n`npm run test` will run the unit tests, using Jasmine as a runner and test framework.\n\n### Publishing\n\nTo publish, simply do:\n\n```bash\nnpm run build\nnpm publish\n```\n\nThat's it!\n","packages/ngtools/webpack/README.md":"# Angular Compiler Webpack Plugin\n\nWebpack 5.x plugin for the Angular Ahead-of-Time compiler. The plugin also supports Angular JIT mode.\nWhen this plugin is used outside of the Angular CLI, the Ivy linker will also be needed to support\nthe usage of Angular libraries. An example configuration of the Babel-based Ivy linker is provided\nin the linker section. For additional information regarding the linker, please see: https://angular.dev/tools/libraries/creating-libraries#consuming-partial-ivy-code-outside-the-angular-cli\n\n## Usage\n\nIn your webpack config, add the following plugin and loader.\n\n```typescript\nimport { AngularWebpackPlugin } from '@ngtools/webpack';\n\nexports = {\n /* ... */\n module: {\n rules: [\n /* ... */\n {\n test: /\\.[jt]sx?$/,\n loader: '@ngtools/webpack',\n },\n ],\n },\n\n plugins: [\n new AngularWebpackPlugin({\n tsconfig: 'path/to/tsconfig.json',\n // ... other options as needed\n }),\n ],\n};\n```\n\nThe loader works with webpack plugin to compile the application's TypeScript. It is important to include both, and to not include any other TypeScript loader.\n\n## Options\n\n- `tsconfig` [default: `tsconfig.json`] - The path to the application's TypeScript Configuration file. In the `tsconfig.json`, you can pass options to the Angular Compiler with `angularCompilerOptions`. Relative paths will be resolved from the Webpack compilation's context.\n- `compilerOptions` [default: none] - Overrides options in the application's TypeScript Configuration file (`tsconfig.json`).\n- `jitMode` [default: `false`] - Enables JIT compilation and do not refactor the code to bootstrap. This replaces `templateUrl: \"string\"` with `template: require(\"string\")` (and similar for styles) to allow for webpack to properly link the resources.\n- `directTemplateLoading` [default: `true`] - Causes the plugin to load component templates (HTML) directly from the filesystem. This is more efficient if only using the `raw-loader` to load component templates. Do not enable this option if additional loaders are configured for component templates.\n- `fileReplacements` [default: none] - Allows replacing TypeScript files with other TypeScript files in the build. This option acts on fully resolved file paths.\n- `inlineStyleFileExtension` [default: none] - When set inline component styles will be processed by Webpack as files with the provided extension.\n\n## Ivy Linker\n\nThe Ivy linker can be setup by using the Webpack `babel-loader` package.\nIf not already installed, add the `babel-loader` package using your project's package manager.\nThen in your webpack config, add the `babel-loader` with the following configuration.\nIf the `babel-loader` is already present in your configuration, the linker plugin can be added to\nthe existing loader configuration as well.\nEnabling caching for the `babel-loader` is recommended to avoid reprocessing libraries on\nevery build.\nFor additional information regarding the `babel-loader` package, please see: https://github.com/babel/babel-loader/tree/main#readme\n\n```typescript\nimport linkerPlugin from '@angular/compiler-cli/linker/babel';\n\nexports = {\n /* ... */\n module: {\n rules: [\n /* ... */\n {\n test: /\\.[cm]?js$/,\n use: {\n loader: 'babel-loader',\n options: {\n cacheDirectory: true,\n compact: false,\n plugins: [linkerPlugin],\n },\n },\n },\n ],\n },\n};\n```\n","packages/schematics/angular/README.md":"# @schematics/angular\n\nThis package contains a collection of [schematics](/packages/angular_devkit/schematics/README.md)\nfor generating an Angular application.\n\n## Schematics\n\n| Name | Description |\n| -------------- | ----------------------------------------------------------------------------------------------------- |\n| app-shell | Generates an app shell for running a server-side version of an app |\n| application | Generates a new basic app definition in the \"projects\" subfolder of the workspace |\n| class | Creates a new, generic class definition in the given project |\n| component | Creates a new, generic component definition in the given project |\n| directive | Creates a new, generic directive definition in the given project |\n| enum | Generates a new, generic enum definition in the given project |\n| guard | Generates a new, generic route guard definition in the given project |\n| interceptor | Creates a new, generic interceptor definition in the given project |\n| interface | Creates a new, generic interface definition in the given project |\n| library | Creates a new, generic library project in the current workspace |\n| module | Creates a new, generic NgModule definition in the given project |\n| ng-new | Creates a new project by combining the workspace and application schematics |\n| pipe | Creates a new, generic pipe definition in the given project |\n| resolver | Creates a new, generic resolver definition in the given project |\n| service | Creates a new, generic service definition in the given project |\n| service-worker | Pass this schematic to the \"run\" command to create a service worker |\n| web-worker | Creates a new, generic web worker definition in the given project |\n| workspace | Initializes an empty workspace and adds the necessary dependencies required by an Angular application |\n\n## Disclaimer\n\nWhile the schematics when executed via the Angular CLI and their associated options are considered stable, the programmatic APIs are not considered officially supported and are not subject to the breaking change guarantees of SemVer.\n","tests/schematics/update/packages/README.md":"\n## Update Package Group packages\n\n* `update-package-group-1@1.0.0` -> `update-package-group2@^1`\n* `update-package-group-2@1.0.0` -> `update-package-group1@1.0.0`\n----\n\n* `update-package-group-1@1.0.0` -> `update-package-group2@^1`\n* `update-package-group-2@1.1.0` -> `update-package-group1@1.0.0`\n----\n\n* `update-package-group-1@1.2.0` -> `update-package-group2@^2`\n* `update-package-group-2@2.0.0` -> `update-package-group1@^1`\n----\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"---\ntrigger: always_on\n---\n\nThis is the source code for the Angular CLI and related build tooling. This guide outlines standard practices for AI agents working in this repository.\n\n## Environment\n\n- Use `pnpm` for package management.\n- Use `pnpm bazel test //target` to run tests.\n\n## Key Documentation\n\n- [Developer Guide](docs/DEVELOPER.md): definitive guide for building, debugging, and running test targets.\n- [Contributing Guide](CONTRIBUTING.md): general contribution workflows and guidelines.\n- [Commit Guidelines](CONTRIBUTING.md#commit): format for commit messages and PR titles.\n\n## Building\n\n- Make a local build of all packages:\n ```shell\n pnpm build --local\n ```\n\n## Coding Practices\n\n- **Imports:**\n - Always use the `node:` protocol for Node.js built-in imports (e.g., `node:fs`, `node:path`, `node:assert`).\n - Prefer named imports (e.g., `import { mkdtemp } from 'node:fs'`) or default imports (`import fs from 'node:fs'`) instead of namespace imports (`import * as fs`).\n - Use type-only imports (`import type { ... }`) when importing types to avoid runtime side-effects.\n- **Classes:**\n - Prefer ECMAScript private fields (`#field`) over TypeScript `private` keywords for encapsulated state.\n\n## Testing\n\n- **Temporary Directories (`TEST_TMPDIR`):**\n - Tests in this repository only run in Bazel. **ALWAYS** use `process.env['TEST_TMPDIR']` and assert that it is set:\n ```ts\n import assert from 'node:assert';\n import { mkdtemp } from 'node:fs/promises';\n import { join } from 'node:path';\n\n describe('...', () => {\n let tempRoot: string;\n\n beforeAll(async () => {\n const baseTmpDir = process.env['TEST_TMPDIR'];\n assert(baseTmpDir, 'TEST_TMPDIR is not set');\n tempRoot = await mkdtemp(join(baseTmpDir, 'angular-cli-test-'));\n });\n });\n ```\n - **NEVER** use or fallback to `os.tmpdir()`. Bazel executes tests in hermetic sandboxes and sets `TEST_TMPDIR` to an isolated, sandboxed directory. Using `os.tmpdir()` can cause sandboxing failures, permission errors, or file leakage outside the Bazel sandbox.\n- **Unit & Integration Tests:**\n - Run all unit and integration tests: `pnpm bazel test //packages/...`\n - Run a specific unit test target (e.g., `pnpm bazel test //packages/angular/build:test`). Note that package `:test` targets may exclude builder integration tests (such as specs under `**/builders/**/tests/**`).\n - Run a specific builder integration test target (e.g., `pnpm bazel test //packages/angular/build:library_integration_tests` or `pnpm bazel test //packages/angular/build:application_integration_tests`).\n - Query all test targets: `pnpm bazel query \"tests(//packages/...)\"`\n - Find the exact test target for a specific spec file (using its workspace-relative path, which Bazel resolves as a source file target): `pnpm bazel query \"kind(jasmine_test, rdeps(//packages/..., ))\"`\n - Focus specific tests when debugging: use `fdescribe()` and `fit()`. NEVER commit focused tests to the repository.\n - Run tests without sharding when isolating or debugging: use `--config=no-sharding` with a specific test target (e.g., `pnpm bazel test //packages/angular/build:library_integration_tests --config=no-sharding`).\n This disables test sharding (`--test_sharding_strategy=disabled`) and flaky test retries (`--flaky_test_attempts=1`).\n This is especially useful when isolating test runs or debugging with focused tests (`fit`/`fdescribe`) to avoid empty shard failures and unnecessary re-runs.\n Do not use this flag when running broad test suites (such as `//packages/...`), as executing tests without sharding takes significantly longer.\n- **End-to-End Tests:**\n - Run subset of E2E tests: `pnpm bazel test //tests:e2e_node22 --config=e2e --test_filter=\"\"`\n\n## Pull Requests\n\n- Use the `gh` CLI (GitHub CLI) for creating and managing pull requests.\n- **Fixup Commits:**\n - When addressing review feedback, **ALWAYS** use fixup commits (`git commit --fixup `) instead of amending existing commits. This preserves commit history during review and allows reviewers to easily see incremental changes.\n - Only use fixup commits for changes that directly belong to the target commit. Unrelated changes must be made in a separate commit with their own commit message, not as a fixup commit.\n - Fixup commits are automatically squashed when merging with `pnpm ng-dev pr merge` or optionally when rebasing with `pnpm ng-dev pr rebase `.\n- Use `pnpm ng-dev pr` commands:\n - `pnpm ng-dev pr rebase `: Rebase a PR branch on its target branch and optionally squash fixup commits.\n - `pnpm ng-dev pr merge `: Merge an approved PR into its targeted branches.\n","frontmatter":{"trigger":"always_on"},"isInternal":false,"tokens":1157,"sizeBytes":4723},{"name":"README.md","path":"packages/angular_devkit/architect/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular_devkit/architect/README.md","title":"architect Documentation","category":"plugin-manifest","format":"markdown","content":"# Angular Build Facade\n\nWIP\n","isInternal":false,"tokens":9,"sizeBytes":28},{"name":"README.md","path":"packages/angular_devkit/architect/src/jobs/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular_devkit/architect/src/jobs/README.md","title":"jobs Documentation","category":"plugin-manifest","format":"markdown","content":"# Description\n\nJobs is the Angular DevKit subsystem for scheduling and running generic functions with clearly\ntyped inputs and outputs. A `Job` instance is a function associated with metadata. You can\nschedule a job, synchronize it with other jobs, and use it to schedule other jobs.\n\nThe whole API is serializable, allowing you to use a Node Stream or message channel to\ncommunicate between the job and the job scheduler.\n\nJobs are lazy, cold, and guaranteed to execute exactly once when scheduled. Subscribing to a job\nreturns messages from the point where the job is at.\n\n## Argument, Input, Output and Channels\n\nA job receives a single argument when scheduled and can also listen to an input channel. It can\nemit multiple outputs, and can also provide multiple output channels that emit asynchronous JSON\nmessages, which can be typed.\n\nThe I/O model is like that of an executable, where the argument corresponds to arguments on the\ncommand line, the input channel to STDIN, the output channel to STDOUT, and the channels\nwould be additional output streams.\n\n## LifeCycle\n\nA `Job` goes through multiple LifeCycle messages before its completion;\n\n1. `JobState.Queued`. The job was queued and is waiting. This is the default state from the\n scheduler.\n1. `JobState.Ready`. The job's dependencies (see\n [\"Synchronizing and Dependencies\"](#Dependencies)) are done running, the argument is\n validated, and the job is ready to execute.\n1. `JobState.Started`. The argument has been validated, the job has been called and is running.\n This is handled by the job itself (or `createJobHandler()`).\n1. `JobState.Ended`. The job has ended and is done running. This is handled by the job itself (or\n `createJobHandler()`).\n1. `JobState.Errored`. A unrecoverable error happened.\n\nEach state (except `Queued`) corresponds to a `JobOutboundMessage` on the `outboundBus` observable\nthat triggers the state change. The `Scheduler` emits the `Ready` and `Errored` messages; the job\nimplementation should not emit them, and if it does they are filtered out. You can listen for\nthese messages or use the corresponding state member.\n\nThe job implementation should emit the `Start` and `End` messages when it is starting the job logic\nitself. Only the first `Start` and `End` messages will be forwarded. Any more will be filtered out.\n\nThe `Queued` state is set as the job is scheduled, so there is no need to listen for the message.\n\n## `Job` Object\n\nThe `Job` object that is returned when you schedule a job provides access to the job's status and\nutilities for tracking and modifying the job.\n\n1. `id`. A unique symbol that can be used as a Map key.\n1. `description`. The description of the job from the scheduler. See `JobDescription` object.\n1. `argument`. The argument value that was used to start the job.\n1. `input`. An `Observer` that can be used to send validated inputs to the job itself.\n1. `output`. An `Observable` that filters out messages to get only the returned output\n of a job.\n1. `promise`. A promise that waits for the last output of a job. Returns the last value outputted\n (or no value if there's no last value).\n1. `state`. The current state of the job (see `LifeCycle`).\n1. `channels`. A map of side channels the user can listen to as `Observable`.\n1. `ping()`. A function that can be used to ping the job, receiving a `Promise` for when the ping\n is answered.\n1. `stop()`. Sends a `stop` input to the job, which suggests to stop the job. The job itself can\n choose to ignore this message.\n1. `inboundBus`. The raw input `Observer`. This can be used to send messages to\n the `context.inboundBus` observable in the job. These are `JobInboundMessage` messages. See\n [\"Communicating With Jobs\"](#Communicating).\n1. `outboundBus`. The raw output `Observable`. This can be used to listen to messages\n from the job. See [\"Communicating With Jobs\"](#Communicating).\n\n## `JobHandlerContext` Object\n\nThe `JobHandlerContext<>` is passed to the job handler code in addition to its argument. The\ncontext contains the following members:\n\n1. `description`. The description of the job. Its name and schemas.\n1. `scheduler`. A `Scheduler<>` instance that can be used to create additional jobs.\n1. `dependencies`. A generic list of other job instances that were run as dependencies when\n scheduling this job. Their `id` is not guaranteed to match the `id` of the `Job<>` instance\n itself (those `Job<>`s might just be proxies). The state of those `Job<>` is guaranteed to be\n `JobState.Ended`, as `JobState.Errored` would have prevented this handler from running.\n1. `inboundBus`. The raw input observable, complement of the `inboundBus` observer from the `Job<>`.\n\n# Examples\n\nAn example of a job that adds all input together and return the output value. We use a\nsimple synchronous job registry and a simple job scheduler.\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\nconst add = jobs.createJobHandle((input) =>\n input.reduce((total, curr) => total + curr, 0),\n);\n\n// Register the job in a SimpleJobRegistry. Different registries have different API.\nconst registry = new jobs.SimpleJobRegistry();\nconst scheduler = new jobs.SimpleScheduler(registry);\nregistry.register(add, {\n name: 'add',\n input: { type: 'array', items: { type: 'number' } },\n output: { type: 'number' },\n});\n\nscheduler\n .schedule('add', [1, 2, 3, 4])\n .promise.then((output) => console.log('1 + 2 + 3 + 4 is ' + output));\n```\n\n# Creating Jobs\n\nA job is at its core a function with a description object attached to it. The description object\nstores the JSON schemas used to validate the types of the argument passed in, the input and\noutput values. By default, a job accepts and can output any JSON object.\n\n```typescript\nimport { Observable } from 'rxjs';\nimport { jobs } from '@angular-devkit/core';\n\nconst argument = {\n type: 'array',\n items: { type: 'number' },\n};\nconst output = {\n type: 'number',\n};\n\nexport function add(argument: number[]): Observable> {\n return new Observable((o) => {\n o.next({ kind: jobs.JobOutboundMessageKind.Start });\n o.next({\n kind: jobs.JobOutboundMessageKind.Output,\n output: argument.reduce((total, curr) => total + curr, 0),\n });\n o.next({ kind: jobs.JobOutboundMessageKind.End });\n o.complete();\n });\n}\n\n// Add a property to `add` to make it officially a JobHandler. The Job system does not recognize\n// any function as a JobHandler.\nadd.jobDescription = {\n argument: argument,\n output: output,\n};\n\n// Call the job with an array as argument, and log its output.\ndeclare const scheduler: jobs.Scheduler;\nscheduler.schedule('add', [1, 2, 3, 4]).output.subscribe((x) => console.log(x)); // Will output 10.\n```\n\nThis is a lot of boilerplate, so we made some helpers to improve readability and manage argument,\ninput and output automatically:\n\n```typescript\n// Add is a JobHandler function, like the above.\nexport const add = jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n);\n\n// Schedule like above.\n```\n\nYou can also return a Promise or an Observable, as jobs are asynchronous. This helper will set\nstart and end messages appropriately. It will also manage channels automatically (see below).\n\nA more complex job can be declared like this:\n\n```typescript\nimport { Observable } from 'rxjs';\nimport { jobs } from '@angular-devkit/core';\n\n// Show progress with each count in a separate output channel. Output \"more\" in a channel.\nexport const count = jobs.createJobHandler(\n // Receive a context that contains additional methods to create channels.\n (argument: number, { createChannel }) =>\n new Observable((o) => {\n const side = createChannel('side', { type: 'string', const: 'more' });\n const progress = createChannel('progress', { type: 'number' });\n let i = 0;\n function doCount() {\n o.next(i++);\n progress.next(i / argument);\n side.next('more');\n\n if (i < argument) {\n setTimeout(doCount, 100);\n } else {\n o.complete();\n }\n }\n setTimeout(doCount, 100);\n }),\n {\n argument: { type: 'number' },\n output: { type: 'number' },\n },\n);\n\n// Get a hold of a scheduler that refers to the job above.\ndeclare const scheduler: jobs.Scheduler;\n\nconst job = scheduler.schedule('count', 0);\njob.getChannel('side').subscribe((x) => console.log(x));\n// You can type a channel too. Messages will be filtered out.\njob.getChannel('progress', { type: 'number' }).subscribe((x) => console.log(x));\n```\n\n## Communicating With Jobs\n\nJobs can be started and updated in a separate process or thread, and as such communication with a\njob should avoid using global objects (which might not be shared). The jobs API and schedulers\nprovide 2 communication streams (one for input and the other for output), named `inboundBus` and\n`outboundBus`.\n\n### Raw Input Stream\n\nThe `schedule()` function returns a `Job<>` interface that contains a `inboundBus` member of type\n`Observer`. All messages sent _to_ the job goes through this stream. The `kind`\nmember of the `JobInboundMessage` interface dictates what kind of message it is sending:\n\n1. `JobInboundMessageKind.Ping`. A simple message that should be answered with\n `JobOutboundMessageKind.Pong` when the job is responsive. The `id` field of the message should\n be used when returning `Pong`.\n1. `JobInboundMessageKind.Stop`. The job should be stopped. This is used when\n cancelling/unsubscribing from the `output` (or by calling `stop()`). Any inputs or outputs\n after this message will be ignored.\n1. `JobInboundMessageKind.Input` is used when sending inputs to a job. These correspond to the\n `next` methods of an `Observer` and are reported to the job through its `context.input`\n Observable. There is no way to communicate an error to the job.\n\nUsing the `createJobHandler()` helper, all those messages are automatically handled by the\nboilerplate code. If you need direct access to raw inputs, you should subscribe to the\n`context.inboundBus` Observable.\n\n### Raw Output Stream\n\nThe `Job<>` interface also contains a `outboundBus` member (of type\n`Observable>` where `O` is the typed output of the job) which is the output\ncomplement of `inboundBus`. All messages sent _from_ the job goes through this stream. The `kind`\nmember of the `JobOutboundMessage` interface dictates what kind of message it is sending:\n\n1. `JobOutboundMessageKind.Create`. The `Job<>` was created, its dependencies are done, and the\n library is validating Argument and calling the internal job code.\n1. `JobOutboundMessageKind.Start`. The job code itself should send that message when started.\n `createJobHandler()` will do it automatically.\n1. `JobOutboundMessageKind.End`. The job has ended. This is done by the job itself and should always\n be sent when completed. The scheduler will listen to this message to set the state and unblock\n dependent jobs. `createJobHandler()` automatically send this message.\n1. `JobOutboundMessageKind.Pong`. The job should answer a `JobInboundMessageKind.Ping` message with\n this. Automatically done by `createJobHandler()`.\n1. `JobOutboundMessageKind.Output`. An `Output` has been generated by the job.\n1. `JobOutboundMessageKind.ChannelMessage`, `JobOutboundMessageKind.ChannelError` and\n `JobOutboundMessageKind.ChannelComplete` are used for output channels. These correspond to the\n `next`, `error` and `complete` methods of an `Observer` and are available to the callee through\n the `job.channels` map of Observable.\n\nThose messages can be accessed directly through the `job.outboundBus` member. The job itself should\nreturn an `Observable>`. The `createJobHandler()` helper handles most of use\ncases of this and makes it easier for jobs to handle this.\n\n## Job Dispatchers\n\nDispatchers are a helper that redirect to different jobs given conditions. To create a job\ndispatcher, use the `createDispatcher()` function:\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\n// A dispatcher that installs node modules given a user's preference.\nconst dispatcher = jobs.createDispatcher({\n name: 'node-install',\n argument: { properties: { moduleName: { type: 'string' } } },\n output: { type: 'boolean' },\n});\n\nconst npmInstall = jobs.createJobHandler(/* ... */, { name: 'npm-install' });\nconst yarnInstall = jobs.createJobHandler(/* ... */, { name: 'yarn-install' });\nconst pnpmInstall = jobs.createJobHandler(/* ... */, { name: 'pnpm-install' });\n\ndeclare const registry: jobs.SimpleJobRegistry;\nregistry.register(dispatcher);\nregistry.register(npmInstall);\nregistry.register(yarnInstall);\nregistry.register(pnpmInstall);\n\n// Default to npm.\ndispatcher.setDefaultDelegate(npmInstall.name);\n// If the user is asking for yarn over npm, uses it.\ndispatcher.addConditionalDelegate(() => userWantsYarn, yarnInstall.name);\n```\n\n## Execution Strategy\n\nJobs are always run in parallel and will always start, but many helper functions are provided\nwhen creating a job to help you control the execution strategy;\n\n1. `serialize()`. Multiple runs of this job will be queued with each others.\n1. `memoize(replayMessages = false)` will create a job, or reuse the same job when inputs are\n matching. If the inputs don't match, a new job will be started and its outputs will be stored.\n\nThese strategies can be used when creating the job:\n\n```typescript\n// Same input and output as above.\n\nexport const add = jobs.strategy.memoize()(\n jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n ),\n);\n```\n\nStrategies can be reused to synchronize between jobs. For example, given jobs `jobA` and `jobB`,\nyou can reuse the strategy to serialize both jobs together;\n\n```typescript\nconst strategy = jobs.strategy.serialize();\nconst jobA = strategy(jobs.createJobHandler(...));\nconst jobB = strategy(jobs.createJobHandler(...));\n```\n\nEven further, we can have package A and package B run in serialization, and B and C also be\nserialized. Running A and C will run in parallel, while running B will wait for both A and C\nto finish.\n\n```typescript\nconst strategy1 = jobs.strategy.serialize();\nconst strategy2 = jobs.strategy.serialize();\nconst jobA = strategy1(jobs.createJobHandler(...));\nconst jobB = strategy1(strategy2(jobs.createJobHandler(...)));\nconst jobC = strategy2(jobs.createJobHandler(...));\n```\n\n# Scheduling Jobs\n\nJobs can be scheduled using a `Scheduler` interface, which contains a `schedule()` method:\n\n```typescript\ninterface Scheduler {\n /**\n * Schedule a job to be run, using its name.\n * @param name The name of job to be run.\n * @param argument The argument to send to the job when starting it.\n * @param options Scheduling options.\n * @returns The Job being run.\n */\n schedule(\n name: JobName,\n argument: I,\n options?: ScheduleJobOptions,\n ): Job;\n}\n```\n\nThe scheduler also has a `getDescription()` method to get a `JobDescription` object for a certain\nname; that description contains schemas for the argument, input, output, and other channels:\n\n```typescript\ninterface Scheduler {\n /**\n * Get a job description for a named job.\n *\n * @param name The name of the job.\n * @returns A description, or null if the job cannot be scheduled.\n */\n getDescription(name: JobName): JobDescription | null;\n\n /**\n * Returns true if the job name has been registered.\n * @param name The name of the job.\n * @returns True if the job exists, false otherwise.\n */\n has(name: JobName): boolean;\n}\n```\n\nFinally, the scheduler interface has a `pause()` method to stop scheduling. This will queue all\njobs and wait for the unpause function to be called before unblocking all the jobs scheduled.\nThis does not affect already running jobs.\n\n```typescript\ninterface Scheduler {\n /**\n * Pause the scheduler, temporary queueing _new_ jobs. Returns a resume function that should be\n * used to resume execution. If multiple `pause()` were called, all their resume functions must\n * be called before the Scheduler actually starts new jobs. Additional calls to the same resume\n * function will have no effect.\n *\n * Jobs already running are NOT paused. This is pausing the scheduler only.\n *\n * @returns A function that can be run to resume the scheduler. If multiple `pause()` calls\n * were made, all their return function must be called (in any order) before the\n * scheduler can resume.\n */\n pause(): () => void;\n}\n```\n\n## Synchronizing and Dependencies\n\nWhen scheduling jobs, it is often necessary to run jobs after certain other jobs are finished.\nThis is done through the `dependencies` options in the `schedule()` method.\n\nThese jobs will also be passed to the job being scheduled, through its context. This can be\nuseful if, for example, the output of those jobs are of a known type, or have known side channels.\n\nAn example of this would be a compiler that needs to know the output directory of other compilers\nbefore it, in a tool chain.\n\n### Dependencies\n\nWhen scheduling jobs, the user can add a `dependencies` field to the scheduling options. The\nscheduler will wait for those dependencies to finish before running the job, and pass those jobs\nin the context of the job.\n\n### Accessing Dependencies\n\nJobs are called with a `JobHandlerContext` as a second argument, which contains a\n`dependencies: Job[]` member which contains all dependencies that were used when\nscheduling the job. Those aren't fully typed as they are determined by the user, and not the job\nitself. They also can contain jobs that are not finished, and the job should use the `state`\nmember of the job itself before trying to access its content.\n\n### Scheduler Sub Jobs\n\nThe `JobHandlerContext` also contains a `scheduler` member which can be used to schedule jobs\nusing the same scheduler that was used for the job. This allows jobs to call other jobs\nand wait for them to end.\n\n## Available Schedulers\n\nThe Core Angular DevKit library provides 2 implementations for the `Scheduler` interface:\n\n## SimpleJobRegistry\n\nAvailable in the jobs namespace. A registry that accept job registration, and can also schedule\njobs.\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\nconst add = jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n);\n\n// Register the job in a SimpleJobRegistry. Different registries have different API.\nconst registry = new jobs.SimpleJobRegistry();\nconst scheduler = new SimpleJobScheduler(registry);\n\nregistry.register(add, {\n name: 'add',\n argument: { type: 'array', items: { type: 'number' } },\n output: { type: 'number' },\n});\n\nscheduler.schedule('add', [1, 2, 3, 4]);\n```\n\n## NodeModuleJobRegistry\n\nAvailable through `@angular-devkit/core/node`.\n\nA scheduler that loads jobs using their node package names. These jobs need to use the\n`createJobHandler()` helper and report their argument/input/output schemas that way.\n\n```typescript\ndeclare const registry: NodeModuleJobRegistry;\nconst scheduler = new SimpleJobScheduler(registry);\n\nscheduler.schedule('some-node-package#someExport', 'input');\n```\n\n# Gotchas\n\n1. Deadlocking Dependencies \n It is impossible to add dependencies to an already running job, but it is entirely possible to\n get locked between jobs. Be aware of your own dependencies.\n\n1. Using `job.promise` \n `job.promise` waits for the job to ends. Don't rely on it unless you know the job is not\n watching and running for a long time. If you aren't sure, use\n `job.output.pipe(first()).toPromise()` instead which will return the first next output,\n regardless of whether the job watches and rerun or not.\n\n# FAQ\n\n1. Laziness \n A job is lazy until executed, but its messages will be replayed when resubscribed.\n\n1. Serialize Strategy vs Dependencies \n Strategies are functions that transform the execution of a job, and can be used when\n declaring the job, or registering it. Dependencies, on the other hand, are listed when\n scheduling a job to order jobs during scheduling.\n\n A job has no control over the way it's scheduled, and its dependencies. It can, however,\n declare that it shouldn't run at the same time as itself. Alternatively, a user could\n schedule a job twice and imply that the second run should wait for the first to finish. In\n practice, this would be equivalent to having the job be serialized, but the important detail\n is in _whom_ is defining the rules; using the `serialize()` strategy, the job implementation\n is, while when using dependencies, the user is.\n\n The user does not need to know how to job needs to synchronize with itself, and the job does\n not need to know how it synchronizes with other jobs that it doesn't know about. That's part\n of the strength of this system as every job can be developed in a vacuum, only caring about\n its contracts (argument, input and output) and its own synchronization.\n","isInternal":false,"tokens":4953,"sizeBytes":21254},{"name":"README.md","path":"packages/angular_devkit/build_angular/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular_devkit/build_angular/README.md","title":"build_angular Documentation","category":"plugin-manifest","format":"markdown","content":"# @angular-devkit/build-angular\n\nThis package contains [Architect builders](/packages/angular_devkit/architect/README.md) used to build and test Angular applications and libraries.\n\n## Builders\n\n| Name | Description |\n| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| application | Build an Angular application targeting a browser and server environment using [esbuild](https://esbuild.github.io). |\n| app-shell | Build an Angular [App shell](https://angular.dev/ecosystem/service-workers/app-shell). |\n| browser | Build an Angular application targeting a browser environment using [Webpack](https://webpack.js.org). |\n| browser-esbuild | Build an Angular application targeting a browser environment using [esbuild](https://esbuild.github.io). |\n| dev-server | A development server that provides live reloading. |\n| extract-i18n | Extract i18n messages from an Angular application. |\n| karma | Execute unit tests using [Karma](https://github.com/karma-runner/karma) test runner. |\n| ng-packagr | Build and package an Angular library in [Angular Package Format (APF)](https://angular.dev/tools/libraries/angular-package-format) format using [ng-packagr](https://github.com/ng-packagr/ng-packagr). |\n| prerender | [Prerender](https://angular.dev/guide/prerendering) pages of your application. Prerendering is the process where a dynamic page is processed at build time generating static HTML. |\n| server | Build an Angular application targeting a [Node.js](https://nodejs.org) environment. |\n| ssr-dev-server | A development server which offers live reload during development, but uses server-side rendering. |\n\n## Disclaimer\n\nWhile the builders when executed via the Angular CLI and their associated options are considered stable, the programmatic APIs are not considered officially supported and are not subject to the breaking change guarantees of SemVer.\n","isInternal":false,"tokens":422,"sizeBytes":3329},{"name":"README.md","path":"packages/angular_devkit/build_webpack/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular_devkit/build_webpack/README.md","title":"build_webpack Documentation","category":"plugin-manifest","format":"markdown","content":"# Webpack Builder for Architect\n\nThis package allows you to run Webpack and Webpack Dev Server using Architect.\n\nTo use it on your Angular CLI app, follow these steps:\n\n- run `npm install @angular-devkit/build-webpack`.\n- create a webpack configuration.\n- add the following targets inside `angular.json`.\n\n```\n \"projects\": {\n \"app\": {\n // ...\n \"architect\": {\n // ...\n \"build-webpack\": {\n \"builder\": \"@angular-devkit/build-webpack:webpack\",\n \"options\": {\n \"webpackConfig\": \"webpack.config.js\"\n }\n },\n \"serve-webpack\": {\n \"builder\": \"@angular-devkit/build-webpack:webpack-dev-server\",\n \"options\": {\n \"webpackConfig\": \"webpack.config.js\"\n }\n }\n }\n```\n\n- run `ng run app:build-webpack` to build, and `ng run app:serve-webpack` to serve.\n\nAll options, including `watch` and `stats`, are looked up inside the webpack configuration.\n","isInternal":false,"tokens":214,"sizeBytes":956},{"name":"README.md","path":"packages/angular_devkit/core/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular_devkit/core/README.md","title":"core Documentation","category":"plugin-manifest","format":"markdown","content":"# Core\n\n> Shared utilities for Angular DevKit.\n\n# Exception\n\n# Json\n\n## Schema\n\n### SchemaValidatorResult\n\n```\nexport interface SchemaValidatorResult {\n success: boolean;\n errors?: string[];\n}\n```\n\n### SchemaValidator\n\n```\nexport interface SchemaValidator {\n (data: any): Observable;\n}\n```\n\n### SchemaFormatter\n\n```\nexport interface SchemaFormatter {\n readonly async: boolean;\n validate(data: any): boolean | Observable;\n}\n```\n\n### SchemaRegistry\n\n```\nexport interface SchemaRegistry {\n compile(schema: Object): Observable;\n addFormat(name: string, formatter: SchemaFormatter): void;\n}\n```\n\n### CoreSchemaRegistry\n\n`SchemaRegistry` implementation using https://github.com/epoberezkin/ajv.\nConstructor accepts object containing `SchemaFormatter` that will be added automatically.\n\n```\nexport class CoreSchemaRegistry implements SchemaRegistry {\n constructor(formats: { [name: string]: SchemaFormatter} = {}) {}\n}\n```\n\n# Logger\n\n# Utils\n\n# Virtual FS\n\n# Workspaces\n\nThe `workspaces` namespace provides an API for interacting with the workspace file formats.\nIt provides an abstraction of the underlying storage format of the workspace and provides\nsupport for both reading and writing. Currently, the only supported format is the JSON-based\nformat used by the Angular CLI. For this format, the API provides internal change tracking of values which\nenables fine-grained updates to the underlying storage of the workspace. This allows for the\nretention of existing formatting and comments.\n\nA workspace is defined via the following object model. Definition collection objects are specialized\nJavascript `Map` objects with an additional `add` method to simplify addition and provide more localized\nerror checking of the newly added values.\n\n```ts\nexport interface WorkspaceDefinition {\n readonly extensions: Record;\n readonly projects: ProjectDefinitionCollection;\n}\n\nexport interface ProjectDefinition {\n readonly extensions: Record;\n readonly targets: TargetDefinitionCollection;\n root: string;\n prefix?: string;\n sourceRoot?: string;\n}\n\nexport interface TargetDefinition {\n options?: Record;\n configurations?: Record | undefined>;\n builder: string;\n}\n```\n\nThe API is asynchronous and has two main functions to facilitate reading, creation, and modifying\na workspace: `readWorkspace` and `writeWorkspace`.\n\n```ts\nexport enum WorkspaceFormat {\n JSON,\n}\n```\n\n```ts\nexport function readWorkspace(\n path: string,\n host: WorkspaceHost,\n format?: WorkspaceFormat,\n): Promise<{ workspace: WorkspaceDefinition }>;\n```\n\n```ts\nexport function writeWorkspace(\n workspace: WorkspaceDefinition,\n host: WorkspaceHost,\n path?: string,\n format?: WorkspaceFormat,\n): Promise;\n```\n\nA `WorkspaceHost` abstracts the underlying data access methods from the functions. It provides\nmethods to read, write, and analyze paths. A utility function is provided to create\nan instance of a `WorkspaceHost` from the Angular DevKit's virtual filesystem host abstraction.\n\n```ts\nexport interface WorkspaceHost {\n readFile(path: string): Promise;\n writeFile(path: string, data: string): Promise;\n isDirectory(path: string): Promise;\n isFile(path: string): Promise;\n}\n\nexport function createWorkspaceHost(host: virtualFs.Host): WorkspaceHost;\n```\n\n## Usage Example\n\nTo demonstrate the usage of the API, the following code will show how to add a option property\nto a build target for an application.\n\n```ts\nimport { NodeJsSyncHost } from '@angular-devkit/core/node';\nimport { workspaces } from '@angular-devkit/core';\n\nasync function demonstrate() {\n const host = workspaces.createWorkspaceHost(new NodeJsSyncHost());\n const { workspace } = await workspaces.readWorkspace('path/to/workspace/directory/', host);\n\n const project = workspace.projects.get('my-app');\n if (!project) {\n throw new Error('my-app does not exist');\n }\n\n const buildTarget = project.targets.get('build');\n if (!buildTarget) {\n throw new Error('build target does not exist');\n }\n\n buildTarget.options.optimization = true;\n\n await workspaces.writeWorkspace(workspace, host);\n}\n\ndemonstrate();\n```\n","isInternal":false,"tokens":908,"sizeBytes":4301},{"name":"README.md","path":"packages/angular_devkit/schematics_cli/blank/project-files/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular_devkit/schematics_cli/blank/project-files/README.md","title":"project-files Documentation","category":"plugin-manifest","format":"markdown","content":"# Getting Started With Schematics\n\nThis repository is a basic Schematic implementation that serves as a starting point to create and publish Schematics to NPM.\n\n### Testing\n\nTo test locally, install `@angular-devkit/schematics-cli` globally and use the `schematics` command line tool. That tool acts the same as the `generate` command of the Angular CLI, but also has a debug mode.\n\nCheck the documentation with\n\n```bash\nschematics --help\n```\n\n### Unit Testing\n\n`npm run test` will run the unit tests, using Jasmine as a runner and test framework.\n\n### Publishing\n\nTo publish, simply do:\n\n```bash\nnpm run build\nnpm publish\n```\n\nThat's it!\n","isInternal":false,"tokens":152,"sizeBytes":639},{"name":"README.md","path":"packages/angular_devkit/schematics_cli/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular_devkit/schematics_cli/README.md","title":"schematics_cli Documentation","category":"plugin-manifest","format":"markdown","content":"# Schematics CLI\n\nThis package contains the executable for running a [Schematic](/packages/angular_devkit/schematics/README.md).\n\n# Usage\n\n```\n$ schematics [CollectionName:]SchematicName [options, ...]\n\nBy default, if the collection name is not specified, use the internal collection provided\nby the Schematics CLI.\n\nOptions:\n --debug Debug mode. This is true by default if the collection is a relative\n path (in that case, turn off with --debug=false).\n\n --allow-private Allow private schematics to be run from the command line. Default to\n false.\n\n --dry-run Do not output anything, but instead just show what actions would be\n performed. Default to true if debug is also true.\n\n --force Force overwriting files that would otherwise be an error.\n\n --list-schematics List all schematics from the collection, by name. A collection name\n should be suffixed by a colon. Example: '@angular-devkit/schematics-cli:'.\n\n --no-interactive Disables interactive input prompts.\n\n --verbose Show more information.\n\n --help Show this message.\n\nAny additional option is passed to the Schematics depending on its schema.\n```\n\n# Examples\n\n1. Create a new NPM package that contains a blank schematic.\n\n```sh\n$ schematics blank \n```\n\n2. Walkthrough example that demonstrates how to build a schematic.\n\n```sh\n$ schematics schematic --name \n```\n","isInternal":false,"tokens":322,"sizeBytes":1519},{"name":"README.md","path":"packages/angular_devkit/schematics_cli/schematic/files/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular_devkit/schematics_cli/schematic/files/README.md","title":"files Documentation","category":"plugin-manifest","format":"markdown","content":"# Getting Started With Schematics\n\nThis repository is a basic Schematic implementation that serves as a starting point to create and publish Schematics to NPM.\n\n### Testing\n\nTo test locally, install `@angular-devkit/schematics-cli` globally and use the `schematics` command line tool. That tool acts the same as the `generate` command of the Angular CLI, but also has a debug mode.\n\nCheck the documentation with\n\n```bash\nschematics --help\n```\n\n### Unit Testing\n\n`npm run test` will run the unit tests, using Jasmine as a runner and test framework.\n\n### Publishing\n\nTo publish, simply do:\n\n```bash\nnpm run build\nnpm publish\n```\n\nThat's it!\n","isInternal":false,"tokens":152,"sizeBytes":639},{"name":"README.md","path":"packages/angular_devkit/schematics/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular_devkit/schematics/README.md","title":"schematics Documentation","category":"plugin-manifest","format":"markdown","content":"# Schematics\n\n> A scaffolding library for the modern web.\n\n## Description\n\nSchematics are generators that transform an existing filesystem. They can create files, refactor existing files, or move files around.\n\nWhat distinguishes Schematics from other generators, such as Yeoman or Yarn Create, is that schematics are purely descriptive; no changes are applied to the actual filesystem until everything is ready to be committed. There is no side effect, by design, in Schematics.\n\n# Glossary\n\n| Term | Description |\n| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Schematics** | A generator that executes descriptive code without side effects on an existing file system. |\n| **Collection** | A list of schematics metadata. Schematics can be referred by name inside a collection. |\n| **Tool** | The code using the Schematics library. |\n| **Tree** | A staging area for changes, containing the original file system, and a list of changes to apply to it. |\n| **Rule** | A function that applies actions to a `Tree`. It returns a new `Tree` that will contain all transformations to be applied. |\n| **Source** | A function that creates an entirely new `Tree` from an empty filesystem. For example, a file source could read files from disk and create a Create Action for each of those. |\n| **Action** | An atomic operation to be validated and committed to a filesystem or a `Tree`. Actions are created by schematics. |\n| **Sink** | The final destination of all `Action`s. |\n| **Task** | A Task is a way to execute an external command or script in a schematic. A Task can be used to perform actions such as installing dependencies, running tests, or building a project. A Task is created by using the `SchematicContext` object and can be scheduled to run before or after the schematic `Tree` is applied. |\n\n# Tooling\n\nSchematics is a library, and does not work by itself. A [reference CLI](https://github.com/angular/angular-cli/blob/main/packages/angular_devkit/schematics_cli/bin/schematics.ts) is available on this repository, and is published on NPM at [@angular-devkit/schematics-cli](https://www.npmjs.com/package/@angular-devkit/schematics-cli). This document explains the library usage and the tooling API, but does not go into the tool implementation itself.\n\nThe tooling is responsible for the following tasks:\n\n1. Create the Schematic Engine, and pass in a Collection and Schematic loader.\n1. Understand and respect the Schematics metadata and dependencies between collections. Schematics can refer to dependencies, and it's the responsibility of the tool to honor those dependencies. The reference CLI uses NPM packages for its collections.\n1. Create the Options object. Options can be anything, but the schematics can specify a JSON Schema that should be respected. The reference CLI, for example, parses the arguments as a JSON object and validates it with the Schema specified by the collection.\n1. Schematics provides some JSON Schema formats for validation that tooling should add. These validate paths, html selectors and app names. Please check the reference CLI for how these can be added.\n1. Call the schematics with the original Tree. The tree should represent the initial state of the filesystem. The reference CLI uses the current directory for this.\n1. Create a Sink and commit the result of the schematics to the Sink. Many sinks are provided by the library; FileSystemSink and DryRunSink are examples.\n1. Output any logs propagated by the library, including debugging information.\n\nThe tooling API is composed of the following pieces:\n\n## Engine\n\nThe `SchematicEngine` is responsible for loading and constructing `Collection`s and `Schematics`. When creating an engine, the tooling provides an `EngineHost` interface that understands how to create a `CollectionDescription` from a name, and how to create a `SchematicDescription`.\n\n# Schematics (Generators)\n\nSchematics are generators and part of a `Collection`.\n\n## Collection\n\nA Collection is defined by a `collection.json` file (in the reference CLI). This JSON defines the following properties:\n\n| Prop Name | Type | Description |\n| ----------- | -------- | --------------------------- |\n| **name** | `string` | The name of the collection. |\n| **version** | `string` | Unused field. |\n\n## Schematic\n\n# Operators, Sources and Rules\n\nA `Source` is a generator of a `Tree`; it creates an entirely new root tree from nothing. A `Rule` is a transformation from one `Tree` to another. A `Schematic` (at the root) is a `Rule` that is normally applied on the filesystem.\n\n## Operators\n\n`FileOperator`s apply changes to a single `FileEntry` and return a new `FileEntry`. The result follows these rules:\n\n1. If the `FileEntry` returned is null, a `DeleteAction` will be added to the action list.\n1. If the path changed, a `RenameAction` will be added to the action list.\n1. If the content changed, an `OverwriteAction` will be added to the action list.\n\nIt is impossible to create files using a `FileOperator`.\n\n## Provided Operators\n\nThe Schematics library provides multiple `Operator` factories by default that cover basic use cases:\n\n| FileOperator | Description |\n| -------------------------------- | -------------------------------------------------------------------- |\n| `contentTemplate(options: T)` | Apply a content template (see the [Templating](#templating) section) |\n| `pathTemplate(options: T)` | Apply a path template (see the [Templating](#templating) section) |\n\n## Provided Sources\n\nThe Schematics library additionally provides multiple `Source` factories by default:\n\n| Source | Description |\n| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |\n| `empty()` | Creates a source that returns an empty `Tree`. |\n| `source(tree: Tree)` | Creates a `Source` that returns the `Tree` passed in as argument. |\n| `url(url: string)` | Loads a list of files from the given URL and returns a `Tree` with the files as `CreateAction` applied to an empty `Tree`. |\n| `apply(source: Source, rules: Rule[])` | Apply a list of `Rule`s to a source, and return the resulting `Source`. |\n\n## Provided Rules\n\nThe schematics library also provides `Rule` factories by default:\n\n| Rule | Description |\n| ------------------------------------------- | -------------------------------------------------------------------------------------- |\n| `noop()` | Returns the input `Tree` as is. |\n| `chain(rules: Rule[])` | Returns a `Rule` that's the concatenation of other `Rule`s. |\n| `forEach(op: FileOperator)` | Returns a `Rule` that applies an operator to every file of the input `Tree`. |\n| `move(root: string)` | Moves all the files from the input to a subdirectory. |\n| `merge(other: Tree)` | Merge the input `Tree` with the other `Tree`. |\n| `contentTemplate(options: T)` | Apply a content template (see the Template section) to the entire `Tree`. |\n| `pathTemplate(options: T)` | Apply a path template (see the Template section) to the entire `Tree`. |\n| `template(options: T)` | Apply both path and content templates (see the Template section) to the entire `Tree`. |\n| `filter(predicate: FilePredicate)` | Returns the input `Tree` with files that do not pass the `FilePredicate`. |\n\n# Templating\n\nAs referenced above, some functions are based upon a file templating system, which consists of path and content templating.\n\nThe system operates on placeholders defined inside files or their paths as loaded in the `Tree` and fills these in as defined in the following, using values passed into the `Rule` which applies the templating (i.e. `template(options: T)`).\n\n## Path Templating\n\n| Placeholder | Description |\n| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- |\n| `__variable__` | Replaced with the value of `variable`. |\n| `__variable@function__` | Replaced with the result of the call `function(variable)`. Can be chained to the left (`__variable@function1@function2__ ` etc). |\n\n## Content Templating\n\n| Placeholder | Description |\n| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |\n| `<%= expression %>` | Replaced with the result of the call of the given expression. This only supports direct expressions, no structural (for/if/...) JavaScript. |\n| `<%- expression %>` | Same as above, but the value of the result will be escaped for HTML when inserted (i.e. replacing '<' with '\\<') |\n| `<% inline code %>` | Inserts the given code into the template structure, allowing to insert structural JavaScript. |\n| `<%# text %>` | A comment, which gets entirely dropped. |\n\n# Examples\n\n## Simple\n\nAn example of a simple Schematics which creates a \"hello world\" file, using an option to determine its path:\n\n```typescript\nimport { Tree } from '@angular-devkit/schematics';\n\nexport default function MySchematic(options: any) {\n return (tree: Tree) => {\n tree.create(options.path + '/hi', 'Hello world!');\n return tree;\n };\n}\n```\n\nA few things from this example:\n\n1. The function receives the list of options from the tooling.\n1. It returns a [`Rule`](src/engine/interface.ts#L73), which is a transformation from a `Tree` to another `Tree`.\n\n## Templating\n\nA simplified example of a Schematics which creates a file containing a new Class, using an option to determine its name:\n\n```typescript\n// files/__name@dasherize__.ts\n\nexport class <%= classify(name) %> {\n}\n```\n\n```typescript\n// index.ts\n\nimport { strings } from '@angular-devkit/core';\nimport {\n Rule,\n SchematicContext,\n SchematicsException,\n Tree,\n apply,\n branchAndMerge,\n mergeWith,\n template,\n url,\n} from '@angular-devkit/schematics';\nimport { Schema as ClassOptions } from './schema';\n\nexport default function (options: ClassOptions): Rule {\n return (tree: Tree, context: SchematicContext) => {\n if (!options.name) {\n throw new SchematicsException('Option (name) is required.');\n }\n\n const templateSource = apply(url('./files'), [\n template({\n ...strings,\n ...options,\n }),\n ]);\n\n return branchAndMerge(mergeWith(templateSource));\n };\n}\n```\n\nAdditional things from this example:\n\n1. `strings` provides the used `dasherize` and `classify` functions, among others.\n1. The files are on-disk in the same root directory as the `index.ts` and loaded into a `Tree`.\n1. Then the `template` `Rule` fills in the specified templating placeholders. For this, it only knows about the variables and functions passed to it via the options-object.\n1. Finally, the resulting `Tree`, containing the new file, is merged with the existing files of the project which the Schematic is run on.\n","isInternal":false,"tokens":2447,"sizeBytes":14766},{"name":"README.md","path":"packages/angular/cli/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular/cli/README.md","title":"cli Documentation","category":"plugin-manifest","format":"markdown","content":"# Angular CLI - The CLI tool for Angular.\n\nThe sources for this package are in the [Angular CLI](https://github.com/angular/angular-cli) repository. Please file issues and pull requests against that repository.\n\nUsage information and reference details can be found in repository [README](https://github.com/angular/angular-cli/blob/main/README.md) file.\n","isInternal":false,"tokens":70,"sizeBytes":354},{"name":"README.md","path":"packages/angular/create/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular/create/README.md","title":"create Documentation","category":"plugin-manifest","format":"markdown","content":"# `@angular/create`\n\n## Create an Angular CLI workspace\n\nScaffold an Angular CLI workspace without needing to install the Angular CLI globally. All of the [ng new](https://angular.dev/cli/new) options and features are supported.\n\n## Usage\n\n### npm\n\n```\nnpm init @angular@latest [project-name] -- [...options]\n```\n\n### yarn\n\n```\nyarn create @angular [project-name] [...options]\n```\n\n### pnpm\n\n```\npnpm create @angular [project-name] [...options]\n```\n\n### bun\n\n```\nbun create @angular [project-name] [...options]\n```\n","isInternal":false,"tokens":130,"sizeBytes":515},{"name":"README.md","path":"packages/angular/pwa/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular/pwa/README.md","title":"pwa Documentation","category":"plugin-manifest","format":"markdown","content":"# `@angular/pwa`\n\nThis is a [schematic](https://angular.dev/tools/cli/schematics) for adding\n[Progressive Web App](https://web.dev/progressive-web-apps/) support to an Angular project. Run the\nschematic with the [Angular CLI](https://angular.dev/tools/cli):\n\n```shell\nng add @angular/pwa --project \n```\n\nExecuting the command mentioned above will perform the following actions:\n\n1. Adds [`@angular/service-worker`](https://npmjs.com/@angular/service-worker) as a dependency to your project.\n1. Enables service worker builds in the Angular CLI.\n1. Imports and registers the service worker in the application module.\n1. Updates the `index.html` file to inlclude a link to add the [manifest.webmanifest](https://developer.mozilla.org/en-US/docs/Web/Manifest) file.\n1. Installs icon files to support the installed Progressive Web App (PWA).\n1. Creates the service worker configuration file called `ngsw-config.json`, specifying caching behaviors and other settings.\n\nSee [Getting started with service workers](https://angular.dev/ecosystem/service-workers/getting-started)\nfor more information.\n","isInternal":false,"tokens":248,"sizeBytes":1105},{"name":"README.md","path":"packages/angular/ssr/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/angular/ssr/README.md","title":"ssr Documentation","category":"plugin-manifest","format":"markdown","content":"# Angular SSR\n\nRead the dev guide [here](https://angular.dev/guide/ssr).\n","isInternal":false,"tokens":20,"sizeBytes":73},{"name":"README.md","path":"packages/ngtools/webpack/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/ngtools/webpack/README.md","title":"webpack Documentation","category":"plugin-manifest","format":"markdown","content":"# Angular Compiler Webpack Plugin\n\nWebpack 5.x plugin for the Angular Ahead-of-Time compiler. The plugin also supports Angular JIT mode.\nWhen this plugin is used outside of the Angular CLI, the Ivy linker will also be needed to support\nthe usage of Angular libraries. An example configuration of the Babel-based Ivy linker is provided\nin the linker section. For additional information regarding the linker, please see: https://angular.dev/tools/libraries/creating-libraries#consuming-partial-ivy-code-outside-the-angular-cli\n\n## Usage\n\nIn your webpack config, add the following plugin and loader.\n\n```typescript\nimport { AngularWebpackPlugin } from '@ngtools/webpack';\n\nexports = {\n /* ... */\n module: {\n rules: [\n /* ... */\n {\n test: /\\.[jt]sx?$/,\n loader: '@ngtools/webpack',\n },\n ],\n },\n\n plugins: [\n new AngularWebpackPlugin({\n tsconfig: 'path/to/tsconfig.json',\n // ... other options as needed\n }),\n ],\n};\n```\n\nThe loader works with webpack plugin to compile the application's TypeScript. It is important to include both, and to not include any other TypeScript loader.\n\n## Options\n\n- `tsconfig` [default: `tsconfig.json`] - The path to the application's TypeScript Configuration file. In the `tsconfig.json`, you can pass options to the Angular Compiler with `angularCompilerOptions`. Relative paths will be resolved from the Webpack compilation's context.\n- `compilerOptions` [default: none] - Overrides options in the application's TypeScript Configuration file (`tsconfig.json`).\n- `jitMode` [default: `false`] - Enables JIT compilation and do not refactor the code to bootstrap. This replaces `templateUrl: \"string\"` with `template: require(\"string\")` (and similar for styles) to allow for webpack to properly link the resources.\n- `directTemplateLoading` [default: `true`] - Causes the plugin to load component templates (HTML) directly from the filesystem. This is more efficient if only using the `raw-loader` to load component templates. Do not enable this option if additional loaders are configured for component templates.\n- `fileReplacements` [default: none] - Allows replacing TypeScript files with other TypeScript files in the build. This option acts on fully resolved file paths.\n- `inlineStyleFileExtension` [default: none] - When set inline component styles will be processed by Webpack as files with the provided extension.\n\n## Ivy Linker\n\nThe Ivy linker can be setup by using the Webpack `babel-loader` package.\nIf not already installed, add the `babel-loader` package using your project's package manager.\nThen in your webpack config, add the `babel-loader` with the following configuration.\nIf the `babel-loader` is already present in your configuration, the linker plugin can be added to\nthe existing loader configuration as well.\nEnabling caching for the `babel-loader` is recommended to avoid reprocessing libraries on\nevery build.\nFor additional information regarding the `babel-loader` package, please see: https://github.com/babel/babel-loader/tree/main#readme\n\n```typescript\nimport linkerPlugin from '@angular/compiler-cli/linker/babel';\n\nexports = {\n /* ... */\n module: {\n rules: [\n /* ... */\n {\n test: /\\.[cm]?js$/,\n use: {\n loader: 'babel-loader',\n options: {\n cacheDirectory: true,\n compact: false,\n plugins: [linkerPlugin],\n },\n },\n },\n ],\n },\n};\n```\n","isInternal":false,"tokens":745,"sizeBytes":3452},{"name":"README.md","path":"packages/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/README.md","title":"packages Documentation","category":"plugin-manifest","format":"markdown","content":"# `/packages` Folder\n\nThis folder is the root of all defined packages in this repository.\n\nPackages that are marked as `private: true` will not be published to NPM.\n\nThis folder includes a directory for every scope in NPM, without the `@` sign. Then one folder\nper package, which contains the `package.json`.\n","isInternal":false,"tokens":70,"sizeBytes":309},{"name":"README.md","path":"packages/schematics/angular/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/packages/schematics/angular/README.md","title":"angular Documentation","category":"plugin-manifest","format":"markdown","content":"# @schematics/angular\n\nThis package contains a collection of [schematics](/packages/angular_devkit/schematics/README.md)\nfor generating an Angular application.\n\n## Schematics\n\n| Name | Description |\n| -------------- | ----------------------------------------------------------------------------------------------------- |\n| app-shell | Generates an app shell for running a server-side version of an app |\n| application | Generates a new basic app definition in the \"projects\" subfolder of the workspace |\n| class | Creates a new, generic class definition in the given project |\n| component | Creates a new, generic component definition in the given project |\n| directive | Creates a new, generic directive definition in the given project |\n| enum | Generates a new, generic enum definition in the given project |\n| guard | Generates a new, generic route guard definition in the given project |\n| interceptor | Creates a new, generic interceptor definition in the given project |\n| interface | Creates a new, generic interface definition in the given project |\n| library | Creates a new, generic library project in the current workspace |\n| module | Creates a new, generic NgModule definition in the given project |\n| ng-new | Creates a new project by combining the workspace and application schematics |\n| pipe | Creates a new, generic pipe definition in the given project |\n| resolver | Creates a new, generic resolver definition in the given project |\n| service | Creates a new, generic service definition in the given project |\n| service-worker | Pass this schematic to the \"run\" command to create a service worker |\n| web-worker | Creates a new, generic web worker definition in the given project |\n| workspace | Initializes an empty workspace and adds the necessary dependencies required by an Angular application |\n\n## Disclaimer\n\nWhile the schematics when executed via the Angular CLI and their associated options are considered stable, the programmatic APIs are not considered officially supported and are not subject to the breaking change guarantees of SemVer.\n","isInternal":false,"tokens":423,"sizeBytes":2886},{"name":"README.md","path":"tests/schematics/update/packages/README.md","rawUrl":"https://raw.githubusercontent.com/angular/angular-cli/HEAD/tests/schematics/update/packages/README.md","title":"packages Documentation","category":"plugin-manifest","format":"markdown","content":"\n## Update Package Group packages\n\n* `update-package-group-1@1.0.0` -> `update-package-group2@^1`\n* `update-package-group-2@1.0.0` -> `update-package-group1@1.0.0`\n----\n\n* `update-package-group-1@1.0.0` -> `update-package-group2@^1`\n* `update-package-group-2@1.1.0` -> `update-package-group1@1.0.0`\n----\n\n* `update-package-group-1@1.2.0` -> `update-package-group2@^2`\n* `update-package-group-2@2.0.0` -> `update-package-group1@^1`\n----\n","isInternal":false,"tokens":160,"sizeBytes":436}],"systemPromptSnippet":"\n\n---\ntrigger: always_on\n---\n\nThis is the source code for the Angular CLI and related build tooling. This guide outlines standard practices for AI agents working in this repository.\n\n## Environment\n\n- Use `pnpm` for package management.\n- Use `pnpm bazel test //target` to run tests.\n\n## Key Documentation\n\n- [Developer Guide](docs/DEVELOPER.md): definitive guide for building, debugging, and running test targets.\n- [Contributing Guide](CONTRIBUTING.md): general contribution workflows and guidelines.\n- [Commit Guidelines](CONTRIBUTING.md#commit): format for commit messages and PR titles.\n\n## Building\n\n- Make a local build of all packages:\n ```shell\n pnpm build --local\n ```\n\n## Coding Practices\n\n- **Imports:**\n - Always use the `node:` protocol for Node.js built-in imports (e.g., `node:fs`, `node:path`, `node:assert`).\n - Prefer named imports (e.g., `import { mkdtemp } from 'node:fs'`) or default imports (`import fs from 'node:fs'`) instead of namespace imports (`import * as fs`).\n - Use type-only imports (`import type { ... }`) when importing types to avoid runtime side-effects.\n- **Classes:**\n - Prefer ECMAScript private fields (`#field`) over TypeScript `private` keywords for encapsulated state.\n\n## Testing\n\n- **Temporary Directories (`TEST_TMPDIR`):**\n - Tests in this repository only run in Bazel. **ALWAYS** use `process.env['TEST_TMPDIR']` and assert that it is set:\n ```ts\n import assert from 'node:assert';\n import { mkdtemp } from 'node:fs/promises';\n import { join } from 'node:path';\n\n describe('...', () => {\n let tempRoot: string;\n\n beforeAll(async () => {\n const baseTmpDir = process.env['TEST_TMPDIR'];\n assert(baseTmpDir, 'TEST_TMPDIR is not set');\n tempRoot = await mkdtemp(join(baseTmpDir, 'angular-cli-test-'));\n });\n });\n ```\n - **NEVER** use or fallback to `os.tmpdir()`. Bazel executes tests in hermetic sandboxes and sets `TEST_TMPDIR` to an isolated, sandboxed directory. Using `os.tmpdir()` can cause sandboxing failures, permission errors, or file leakage outside the Bazel sandbox.\n- **Unit & Integration Tests:**\n - Run all unit and integration tests: `pnpm bazel test //packages/...`\n - Run a specific unit test target (e.g., `pnpm bazel test //packages/angular/build:test`). Note that package `:test` targets may exclude builder integration tests (such as specs under `**/builders/**/tests/**`).\n - Run a specific builder integration test target (e.g., `pnpm bazel test //packages/angular/build:library_integration_tests` or `pnpm bazel test //packages/angular/build:application_integration_tests`).\n - Query all test targets: `pnpm bazel query \"tests(//packages/...)\"`\n - Find the exact test target for a specific spec file (using its workspace-relative path, which Bazel resolves as a source file target): `pnpm bazel query \"kind(jasmine_test, rdeps(//packages/..., ))\"`\n - Focus specific tests when debugging: use `fdescribe()` and `fit()`. NEVER commit focused tests to the repository.\n - Run tests without sharding when isolating or debugging: use `--config=no-sharding` with a specific test target (e.g., `pnpm bazel test //packages/angular/build:library_integration_tests --config=no-sharding`).\n This disables test sharding (`--test_sharding_strategy=disabled`) and flaky test retries (`--flaky_test_attempts=1`).\n This is especially useful when isolating test runs or debugging with focused tests (`fit`/`fdescribe`) to avoid empty shard failures and unnecessary re-runs.\n Do not use this flag when running broad test suites (such as `//packages/...`), as executing tests without sharding takes significantly longer.\n- **End-to-End Tests:**\n - Run subset of E2E tests: `pnpm bazel test //tests:e2e_node22 --config=e2e --test_filter=\"\"`\n\n## Pull Requests\n\n- Use the `gh` CLI (GitHub CLI) for creating and managing pull requests.\n- **Fixup Commits:**\n - When addressing review feedback, **ALWAYS** use fixup commits (`git commit --fixup `) instead of amending existing commits. This preserves commit history during review and allows reviewers to easily see incremental changes.\n - Only use fixup commits for changes that directly belong to the target commit. Unrelated changes must be made in a separate commit with their own commit message, not as a fixup commit.\n - Fixup commits are automatically squashed when merging with `pnpm ng-dev pr merge` or optionally when rebasing with `pnpm ng-dev pr rebase `.\n- Use `pnpm ng-dev pr` commands:\n - `pnpm ng-dev pr rebase `: Rebase a PR branch on its target branch and optionally squash fixup commits.\n - `pnpm ng-dev pr merge `: Merge an approved PR into its targeted branches.\n\n\n# Angular Build Facade\n\nWIP\n\n\n# Description\n\nJobs is the Angular DevKit subsystem for scheduling and running generic functions with clearly\ntyped inputs and outputs. A `Job` instance is a function associated with metadata. You can\nschedule a job, synchronize it with other jobs, and use it to schedule other jobs.\n\nThe whole API is serializable, allowing you to use a Node Stream or message channel to\ncommunicate between the job and the job scheduler.\n\nJobs are lazy, cold, and guaranteed to execute exactly once when scheduled. Subscribing to a job\nreturns messages from the point where the job is at.\n\n## Argument, Input, Output and Channels\n\nA job receives a single argument when scheduled and can also listen to an input channel. It can\nemit multiple outputs, and can also provide multiple output channels that emit asynchronous JSON\nmessages, which can be typed.\n\nThe I/O model is like that of an executable, where the argument corresponds to arguments on the\ncommand line, the input channel to STDIN, the output channel to STDOUT, and the channels\nwould be additional output streams.\n\n## LifeCycle\n\nA `Job` goes through multiple LifeCycle messages before its completion;\n\n1. `JobState.Queued`. The job was queued and is waiting. This is the default state from the\n scheduler.\n1. `JobState.Ready`. The job's dependencies (see\n [\"Synchronizing and Dependencies\"](#Dependencies)) are done running, the argument is\n validated, and the job is ready to execute.\n1. `JobState.Started`. The argument has been validated, the job has been called and is running.\n This is handled by the job itself (or `createJobHandler()`).\n1. `JobState.Ended`. The job has ended and is done running. This is handled by the job itself (or\n `createJobHandler()`).\n1. `JobState.Errored`. A unrecoverable error happened.\n\nEach state (except `Queued`) corresponds to a `JobOutboundMessage` on the `outboundBus` observable\nthat triggers the state change. The `Scheduler` emits the `Ready` and `Errored` messages; the job\nimplementation should not emit them, and if it does they are filtered out. You can listen for\nthese messages or use the corresponding state member.\n\nThe job implementation should emit the `Start` and `End` messages when it is starting the job logic\nitself. Only the first `Start` and `End` messages will be forwarded. Any more will be filtered out.\n\nThe `Queued` state is set as the job is scheduled, so there is no need to listen for the message.\n\n## `Job` Object\n\nThe `Job` object that is returned when you schedule a job provides access to the job's status and\nutilities for tracking and modifying the job.\n\n1. `id`. A unique symbol that can be used as a Map key.\n1. `description`. The description of the job from the scheduler. See `JobDescription` object.\n1. `argument`. The argument value that was used to start the job.\n1. `input`. An `Observer` that can be used to send validated inputs to the job itself.\n1. `output`. An `Observable` that filters out messages to get only the returned output\n of a job.\n1. `promise`. A promise that waits for the last output of a job. Returns the last value outputted\n (or no value if there's no last value).\n1. `state`. The current state of the job (see `LifeCycle`).\n1. `channels`. A map of side channels the user can listen to as `Observable`.\n1. `ping()`. A function that can be used to ping the job, receiving a `Promise` for when the ping\n is answered.\n1. `stop()`. Sends a `stop` input to the job, which suggests to stop the job. The job itself can\n choose to ignore this message.\n1. `inboundBus`. The raw input `Observer`. This can be used to send messages to\n the `context.inboundBus` observable in the job. These are `JobInboundMessage` messages. See\n [\"Communicating With Jobs\"](#Communicating).\n1. `outboundBus`. The raw output `Observable`. This can be used to listen to messages\n from the job. See [\"Communicating With Jobs\"](#Communicating).\n\n## `JobHandlerContext` Object\n\nThe `JobHandlerContext<>` is passed to the job handler code in addition to its argument. The\ncontext contains the following members:\n\n1. `description`. The description of the job. Its name and schemas.\n1. `scheduler`. A `Scheduler<>` instance that can be used to create additional jobs.\n1. `dependencies`. A generic list of other job instances that were run as dependencies when\n scheduling this job. Their `id` is not guaranteed to match the `id` of the `Job<>` instance\n itself (those `Job<>`s might just be proxies). The state of those `Job<>` is guaranteed to be\n `JobState.Ended`, as `JobState.Errored` would have prevented this handler from running.\n1. `inboundBus`. The raw input observable, complement of the `inboundBus` observer from the `Job<>`.\n\n# Examples\n\nAn example of a job that adds all input together and return the output value. We use a\nsimple synchronous job registry and a simple job scheduler.\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\nconst add = jobs.createJobHandle((input) =>\n input.reduce((total, curr) => total + curr, 0),\n);\n\n// Register the job in a SimpleJobRegistry. Different registries have different API.\nconst registry = new jobs.SimpleJobRegistry();\nconst scheduler = new jobs.SimpleScheduler(registry);\nregistry.register(add, {\n name: 'add',\n input: { type: 'array', items: { type: 'number' } },\n output: { type: 'number' },\n});\n\nscheduler\n .schedule('add', [1, 2, 3, 4])\n .promise.then((output) => console.log('1 + 2 + 3 + 4 is ' + output));\n```\n\n# Creating Jobs\n\nA job is at its core a function with a description object attached to it. The description object\nstores the JSON schemas used to validate the types of the argument passed in, the input and\noutput values. By default, a job accepts and can output any JSON object.\n\n```typescript\nimport { Observable } from 'rxjs';\nimport { jobs } from '@angular-devkit/core';\n\nconst argument = {\n type: 'array',\n items: { type: 'number' },\n};\nconst output = {\n type: 'number',\n};\n\nexport function add(argument: number[]): Observable> {\n return new Observable((o) => {\n o.next({ kind: jobs.JobOutboundMessageKind.Start });\n o.next({\n kind: jobs.JobOutboundMessageKind.Output,\n output: argument.reduce((total, curr) => total + curr, 0),\n });\n o.next({ kind: jobs.JobOutboundMessageKind.End });\n o.complete();\n });\n}\n\n// Add a property to `add` to make it officially a JobHandler. The Job system does not recognize\n// any function as a JobHandler.\nadd.jobDescription = {\n argument: argument,\n output: output,\n};\n\n// Call the job with an array as argument, and log its output.\ndeclare const scheduler: jobs.Scheduler;\nscheduler.schedule('add', [1, 2, 3, 4]).output.subscribe((x) => console.log(x)); // Will output 10.\n```\n\nThis is a lot of boilerplate, so we made some helpers to improve readability and manage argument,\ninput and output automatically:\n\n```typescript\n// Add is a JobHandler function, like the above.\nexport const add = jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n);\n\n// Schedule like above.\n```\n\nYou can also return a Promise or an Observable, as jobs are asynchronous. This helper will set\nstart and end messages appropriately. It will also manage channels automatically (see below).\n\nA more complex job can be declared like this:\n\n```typescript\nimport { Observable } from 'rxjs';\nimport { jobs } from '@angular-devkit/core';\n\n// Show progress with each count in a separate output channel. Output \"more\" in a channel.\nexport const count = jobs.createJobHandler(\n // Receive a context that contains additional methods to create channels.\n (argument: number, { createChannel }) =>\n new Observable((o) => {\n const side = createChannel('side', { type: 'string', const: 'more' });\n const progress = createChannel('progress', { type: 'number' });\n let i = 0;\n function doCount() {\n o.next(i++);\n progress.next(i / argument);\n side.next('more');\n\n if (i < argument) {\n setTimeout(doCount, 100);\n } else {\n o.complete();\n }\n }\n setTimeout(doCount, 100);\n }),\n {\n argument: { type: 'number' },\n output: { type: 'number' },\n },\n);\n\n// Get a hold of a scheduler that refers to the job above.\ndeclare const scheduler: jobs.Scheduler;\n\nconst job = scheduler.schedule('count', 0);\njob.getChannel('side').subscribe((x) => console.log(x));\n// You can type a channel too. Messages will be filtered out.\njob.getChannel('progress', { type: 'number' }).subscribe((x) => console.log(x));\n```\n\n## Communicating With Jobs\n\nJobs can be started and updated in a separate process or thread, and as such communication with a\njob should avoid using global objects (which might not be shared). The jobs API and schedulers\nprovide 2 communication streams (one for input and the other for output), named `inboundBus` and\n`outboundBus`.\n\n### Raw Input Stream\n\nThe `schedule()` function returns a `Job<>` interface that contains a `inboundBus` member of type\n`Observer`. All messages sent _to_ the job goes through this stream. The `kind`\nmember of the `JobInboundMessage` interface dictates what kind of message it is sending:\n\n1. `JobInboundMessageKind.Ping`. A simple message that should be answered with\n `JobOutboundMessageKind.Pong` when the job is responsive. The `id` field of the message should\n be used when returning `Pong`.\n1. `JobInboundMessageKind.Stop`. The job should be stopped. This is used when\n cancelling/unsubscribing from the `output` (or by calling `stop()`). Any inputs or outputs\n after this message will be ignored.\n1. `JobInboundMessageKind.Input` is used when sending inputs to a job. These correspond to the\n `next` methods of an `Observer` and are reported to the job through its `context.input`\n Observable. There is no way to communicate an error to the job.\n\nUsing the `createJobHandler()` helper, all those messages are automatically handled by the\nboilerplate code. If you need direct access to raw inputs, you should subscribe to the\n`context.inboundBus` Observable.\n\n### Raw Output Stream\n\nThe `Job<>` interface also contains a `outboundBus` member (of type\n`Observable>` where `O` is the typed output of the job) which is the output\ncomplement of `inboundBus`. All messages sent _from_ the job goes through this stream. The `kind`\nmember of the `JobOutboundMessage` interface dictates what kind of message it is sending:\n\n1. `JobOutboundMessageKind.Create`. The `Job<>` was created, its dependencies are done, and the\n library is validating Argument and calling the internal job code.\n1. `JobOutboundMessageKind.Start`. The job code itself should send that message when started.\n `createJobHandler()` will do it automatically.\n1. `JobOutboundMessageKind.End`. The job has ended. This is done by the job itself and should always\n be sent when completed. The scheduler will listen to this message to set the state and unblock\n dependent jobs. `createJobHandler()` automatically send this message.\n1. `JobOutboundMessageKind.Pong`. The job should answer a `JobInboundMessageKind.Ping` message with\n this. Automatically done by `createJobHandler()`.\n1. `JobOutboundMessageKind.Output`. An `Output` has been generated by the job.\n1. `JobOutboundMessageKind.ChannelMessage`, `JobOutboundMessageKind.ChannelError` and\n `JobOutboundMessageKind.ChannelComplete` are used for output channels. These correspond to the\n `next`, `error` and `complete` methods of an `Observer` and are available to the callee through\n the `job.channels` map of Observable.\n\nThose messages can be accessed directly through the `job.outboundBus` member. The job itself should\nreturn an `Observable>`. The `createJobHandler()` helper handles most of use\ncases of this and makes it easier for jobs to handle this.\n\n## Job Dispatchers\n\nDispatchers are a helper that redirect to different jobs given conditions. To create a job\ndispatcher, use the `createDispatcher()` function:\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\n// A dispatcher that installs node modules given a user's preference.\nconst dispatcher = jobs.createDispatcher({\n name: 'node-install',\n argument: { properties: { moduleName: { type: 'string' } } },\n output: { type: 'boolean' },\n});\n\nconst npmInstall = jobs.createJobHandler(/* ... */, { name: 'npm-install' });\nconst yarnInstall = jobs.createJobHandler(/* ... */, { name: 'yarn-install' });\nconst pnpmInstall = jobs.createJobHandler(/* ... */, { name: 'pnpm-install' });\n\ndeclare const registry: jobs.SimpleJobRegistry;\nregistry.register(dispatcher);\nregistry.register(npmInstall);\nregistry.register(yarnInstall);\nregistry.register(pnpmInstall);\n\n// Default to npm.\ndispatcher.setDefaultDelegate(npmInstall.name);\n// If the user is asking for yarn over npm, uses it.\ndispatcher.addConditionalDelegate(() => userWantsYarn, yarnInstall.name);\n```\n\n## Execution Strategy\n\nJobs are always run in parallel and will always start, but many helper functions are provided\nwhen creating a job to help you control the execution strategy;\n\n1. `serialize()`. Multiple runs of this job will be queued with each others.\n1. `memoize(replayMessages = false)` will create a job, or reuse the same job when inputs are\n matching. If the inputs don't match, a new job will be started and its outputs will be stored.\n\nThese strategies can be used when creating the job:\n\n```typescript\n// Same input and output as above.\n\nexport const add = jobs.strategy.memoize()(\n jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n ),\n);\n```\n\nStrategies can be reused to synchronize between jobs. For example, given jobs `jobA` and `jobB`,\nyou can reuse the strategy to serialize both jobs together;\n\n```typescript\nconst strategy = jobs.strategy.serialize();\nconst jobA = strategy(jobs.createJobHandler(...));\nconst jobB = strategy(jobs.createJobHandler(...));\n```\n\nEven further, we can have package A and package B run in serialization, and B and C also be\nserialized. Running A and C will run in parallel, while running B will wait for both A and C\nto finish.\n\n```typescript\nconst strategy1 = jobs.strategy.serialize();\nconst strategy2 = jobs.strategy.serialize();\nconst jobA = strategy1(jobs.createJobHandler(...));\nconst jobB = strategy1(strategy2(jobs.createJobHandler(...)));\nconst jobC = strategy2(jobs.createJobHandler(...));\n```\n\n# Scheduling Jobs\n\nJobs can be scheduled using a `Scheduler` interface, which contains a `schedule()` method:\n\n```typescript\ninterface Scheduler {\n /**\n * Schedule a job to be run, using its name.\n * @param name The name of job to be run.\n * @param argument The argument to send to the job when starting it.\n * @param options Scheduling options.\n * @returns The Job being run.\n */\n schedule(\n name: JobName,\n argument: I,\n options?: ScheduleJobOptions,\n ): Job;\n}\n```\n\nThe scheduler also has a `getDescription()` method to get a `JobDescription` object for a certain\nname; that description contains schemas for the argument, input, output, and other channels:\n\n```typescript\ninterface Scheduler {\n /**\n * Get a job description for a named job.\n *\n * @param name The name of the job.\n * @returns A description, or null if the job cannot be scheduled.\n */\n getDescription(name: JobName): JobDescription | null;\n\n /**\n * Returns true if the job name has been registered.\n * @param name The name of the job.\n * @returns True if the job exists, false otherwise.\n */\n has(name: JobName): boolean;\n}\n```\n\nFinally, the scheduler interface has a `pause()` method to stop scheduling. This will queue all\njobs and wait for the unpause function to be called before unblocking all the jobs scheduled.\nThis does not affect already running jobs.\n\n```typescript\ninterface Scheduler {\n /**\n * Pause the scheduler, temporary queueing _new_ jobs. Returns a resume function that should be\n * used to resume execution. If multiple `pause()` were called, all their resume functions must\n * be called before the Scheduler actually starts new jobs. Additional calls to the same resume\n * function will have no effect.\n *\n * Jobs already running are NOT paused. This is pausing the scheduler only.\n *\n * @returns A function that can be run to resume the scheduler. If multiple `pause()` calls\n * were made, all their return function must be called (in any order) before the\n * scheduler can resume.\n */\n pause(): () => void;\n}\n```\n\n## Synchronizing and Dependencies\n\nWhen scheduling jobs, it is often necessary to run jobs after certain other jobs are finished.\nThis is done through the `dependencies` options in the `schedule()` method.\n\nThese jobs will also be passed to the job being scheduled, through its context. This can be\nuseful if, for example, the output of those jobs are of a known type, or have known side channels.\n\nAn example of this would be a compiler that needs to know the output directory of other compilers\nbefore it, in a tool chain.\n\n### Dependencies\n\nWhen scheduling jobs, the user can add a `dependencies` field to the scheduling options. The\nscheduler will wait for those dependencies to finish before running the job, and pass those jobs\nin the context of the job.\n\n### Accessing Dependencies\n\nJobs are called with a `JobHandlerContext` as a second argument, which contains a\n`dependencies: Job[]` member which contains all dependencies that were used when\nscheduling the job. Those aren't fully typed as they are determined by the user, and not the job\nitself. They also can contain jobs that are not finished, and the job should use the `state`\nmember of the job itself before trying to access its content.\n\n### Scheduler Sub Jobs\n\nThe `JobHandlerContext` also contains a `scheduler` member which can be used to schedule jobs\nusing the same scheduler that was used for the job. This allows jobs to call other jobs\nand wait for them to end.\n\n## Available Schedulers\n\nThe Core Angular DevKit library provides 2 implementations for the `Scheduler` interface:\n\n## SimpleJobRegistry\n\nAvailable in the jobs namespace. A registry that accept job registration, and can also schedule\njobs.\n\n```typescript\nimport { jobs } from '@angular-devkit/core';\n\nconst add = jobs.createJobHandler((argument) =>\n argument.reduce((total, curr) => total + curr, 0),\n);\n\n// Register the job in a SimpleJobRegistry. Different registries have different API.\nconst registry = new jobs.SimpleJobRegistry();\nconst scheduler = new SimpleJobScheduler(registry);\n\nregistry.register(add, {\n name: 'add',\n argument: { type: 'array', items: { type: 'number' } },\n output: { type: 'number' },\n});\n\nscheduler.schedule('add', [1, 2, 3, 4]);\n```\n\n## NodeModuleJobRegistry\n\nAvailable through `@angular-devkit/core/node`.\n\nA scheduler that loads jobs using their node package names. These jobs need to use the\n`createJobHandler()` helper and report their argument/input/output schemas that way.\n\n```typescript\ndeclare const registry: NodeModuleJobRegistry;\nconst scheduler = new SimpleJobScheduler(registry);\n\nscheduler.schedule('some-node-package#someExport', 'input');\n```\n\n# Gotchas\n\n1. Deadlocking Dependencies \n It is impossible to add dependencies to an already running job, but it is entirely possible to\n get locked between jobs. Be aware of your own dependencies.\n\n1. Using `job.promise` \n `job.promise` waits for the job to ends. Don't rely on it unless you know the job is not\n watching and running for a long time. If you aren't sure, use\n `job.output.pipe(first()).toPromise()` instead which will return the first next output,\n regardless of whether the job watches and rerun or not.\n\n# FAQ\n\n1. Laziness \n A job is lazy until executed, but its messages will be replayed when resubscribed.\n\n1. Serialize Strategy vs Dependencies \n Strategies are functions that transform the execution of a job, and can be used when\n declaring the job, or registering it. Dependencies, on the other hand, are listed when\n scheduling a job to order jobs during scheduling.\n\n A job has no control over the way it's scheduled, and its dependencies. It can, however,\n declare that it shouldn't run at the same time as itself. Alternatively, a user could\n schedule a job twice and imply that the second run should wait for the first to finish. In\n practice, this would be equivalent to having the job be serialized, but the important detail\n is in _whom_ is defining the rules; using the `serialize()` strategy, the job implementation\n is, while when using dependencies, the user is.\n\n The user does not need to know how to job needs to synchronize with itself, and the job does\n not need to know how it synchronizes with other jobs that it doesn't know about. That's part\n of the strength of this system as every job can be developed in a vacuum, only caring about\n its contracts (argument, input and output) and its own synchronization.\n\n\n# @angular-devkit/build-angular\n\nThis package contains [Architect builders](/packages/angular_devkit/architect/README.md) used to build and test Angular applications and libraries.\n\n## Builders\n\n| Name | Description |\n| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| application | Build an Angular application targeting a browser and server environment using [esbuild](https://esbuild.github.io). |\n| app-shell | Build an Angular [App shell](https://angular.dev/ecosystem/service-workers/app-shell). |\n| browser | Build an Angular application targeting a browser environment using [Webpack](https://webpack.js.org). |\n| browser-esbuild | Build an Angular application targeting a browser environment using [esbuild](https://esbuild.github.io). |\n| dev-server | A development server that provides live reloading. |\n| extract-i18n | Extract i18n messages from an Angular application. |\n| karma | Execute unit tests using [Karma](https://github.com/karma-runner/karma) test runner. |\n| ng-packagr | Build and package an Angular library in [Angular Package Format (APF)](https://angular.dev/tools/libraries/angular-package-format) format using [ng-packagr](https://github.com/ng-packagr/ng-packagr). |\n| prerender | [Prerender](https://angular.dev/guide/prerendering) pages of your application. Prerendering is the process where a dynamic page is processed at build time generating static HTML. |\n| server | Build an Angular application targeting a [Node.js](https://nodejs.org) environment. |\n| ssr-dev-server | A development server which offers live reload during development, but uses server-side rendering. |\n\n## Disclaimer\n\nWhile the builders when executed via the Angular CLI and their associated options are considered stable, the programmatic APIs are not considered officially supported and are not subject to the breaking change guarantees of SemVer.\n\n\n# Webpack Builder for Architect\n\nThis package allows you to run Webpack and Webpack Dev Server using Architect.\n\nTo use it on your Angular CLI app, follow these steps:\n\n- run `npm install @angular-devkit/build-webpack`.\n- create a webpack configuration.\n- add the following targets inside `angular.json`.\n\n```\n \"projects\": {\n \"app\": {\n // ...\n \"architect\": {\n // ...\n \"build-webpack\": {\n \"builder\": \"@angular-devkit/build-webpack:webpack\",\n \"options\": {\n \"webpackConfig\": \"webpack.config.js\"\n }\n },\n \"serve-webpack\": {\n \"builder\": \"@angular-devkit/build-webpack:webpack-dev-server\",\n \"options\": {\n \"webpackConfig\": \"webpack.config.js\"\n }\n }\n }\n```\n\n- run `ng run app:build-webpack` to build, and `ng run app:serve-webpack` to serve.\n\nAll options, including `watch` and `stats`, are looked up inside the webpack configuration.\n\n\n# Core\n\n> Shared utilities for Angular DevKit.\n\n# Exception\n\n# Json\n\n## Schema\n\n### SchemaValidatorResult\n\n```\nexport interface SchemaValidatorResult {\n success: boolean;\n errors?: string[];\n}\n```\n\n### SchemaValidator\n\n```\nexport interface SchemaValidator {\n (data: any): Observable;\n}\n```\n\n### SchemaFormatter\n\n```\nexport interface SchemaFormatter {\n readonly async: boolean;\n validate(data: any): boolean | Observable;\n}\n```\n\n### SchemaRegistry\n\n```\nexport interface SchemaRegistry {\n compile(schema: Object): Observable;\n addFormat(name: string, formatter: SchemaFormatter): void;\n}\n```\n\n### CoreSchemaRegistry\n\n`SchemaRegistry` implementation using https://github.com/epoberezkin/ajv.\nConstructor accepts object containing `SchemaFormatter` that will be added automatically.\n\n```\nexport class CoreSchemaRegistry implements SchemaRegistry {\n constructor(formats: { [name: string]: SchemaFormatter} = {}) {}\n}\n```\n\n# Logger\n\n# Utils\n\n# Virtual FS\n\n# Workspaces\n\nThe `workspaces` namespace provides an API for interacting with the workspace file formats.\nIt provides an abstraction of the underlying storage format of the workspace and provides\nsupport for both reading and writing. Currently, the only supported format is the JSON-based\nformat used by the Angular CLI. For this format, the API provides internal change tracking of values which\nenables fine-grained updates to the underlying storage of the workspace. This allows for the\nretention of existing formatting and comments.\n\nA workspace is defined via the following object model. Definition collection objects are specialized\nJavascript `Map` objects with an additional `add` method to simplify addition and provide more localized\nerror checking of the newly added values.\n\n```ts\nexport interface WorkspaceDefinition {\n readonly extensions: Record;\n readonly projects: ProjectDefinitionCollection;\n}\n\nexport interface ProjectDefinition {\n readonly extensions: Record;\n readonly targets: TargetDefinitionCollection;\n root: string;\n prefix?: string;\n sourceRoot?: string;\n}\n\nexport interface TargetDefinition {\n options?: Record;\n configurations?: Record | undefined>;\n builder: string;\n}\n```\n\nThe API is asynchronous and has two main functions to facilitate reading, creation, and modifying\na workspace: `readWorkspace` and `writeWorkspace`.\n\n```ts\nexport enum WorkspaceFormat {\n JSON,\n}\n```\n\n```ts\nexport function readWorkspace(\n path: string,\n host: WorkspaceHost,\n format?: WorkspaceFormat,\n): Promise<{ workspace: WorkspaceDefinition }>;\n```\n\n```ts\nexport function writeWorkspace(\n workspace: WorkspaceDefinition,\n host: WorkspaceHost,\n path?: string,\n format?: WorkspaceFormat,\n): Promise;\n```\n\nA `WorkspaceHost` abstracts the underlying data access methods from the functions. It provides\nmethods to read, write, and analyze paths. A utility function is provided to create\nan instance of a `WorkspaceHost` from the Angular DevKit's virtual filesystem host abstraction.\n\n```ts\nexport interface WorkspaceHost {\n readFile(path: string): Promise;\n writeFile(path: string, data: string): Promise;\n isDirectory(path: string): Promise;\n isFile(path: string): Promise;\n}\n\nexport function createWorkspaceHost(host: virtualFs.Host): WorkspaceHost;\n```\n\n## Usage Example\n\nTo demonstrate the usage of the API, the following code will show how to add a option property\nto a build target for an application.\n\n```ts\nimport { NodeJsSyncHost } from '@angular-devkit/core/node';\nimport { workspaces } from '@angular-devkit/core';\n\nasync function demonstrate() {\n const host = workspaces.createWorkspaceHost(new NodeJsSyncHost());\n const { workspace } = await workspaces.readWorkspace('path/to/workspace/directory/', host);\n\n const project = workspace.projects.get('my-app');\n if (!project) {\n throw new Error('my-app does not exist');\n }\n\n const buildTarget = project.targets.get('build');\n if (!buildTarget) {\n throw new Error('build target does not exist');\n }\n\n buildTarget.options.optimization = true;\n\n await workspaces.writeWorkspace(workspace, host);\n}\n\ndemonstrate();\n```\n\n\n# Getting Started With Schematics\n\nThis repository is a basic Schematic implementation that serves as a starting point to create and publish Schematics to NPM.\n\n### Testing\n\nTo test locally, install `@angular-devkit/schematics-cli` globally and use the `schematics` command line tool. That tool acts the same as the `generate` command of the Angular CLI, but also has a debug mode.\n\nCheck the documentation with\n\n```bash\nschematics --help\n```\n\n### Unit Testing\n\n`npm run test` will run the unit tests, using Jasmine as a runner and test framework.\n\n### Publishing\n\nTo publish, simply do:\n\n```bash\nnpm run build\nnpm publish\n```\n\nThat's it!\n\n\n# Schematics CLI\n\nThis package contains the executable for running a [Schematic](/packages/angular_devkit/schematics/README.md).\n\n# Usage\n\n```\n$ schematics [CollectionName:]SchematicName [options, ...]\n\nBy default, if the collection name is not specified, use the internal collection provided\nby the Schematics CLI.\n\nOptions:\n --debug Debug mode. This is true by default if the collection is a relative\n path (in that case, turn off with --debug=false).\n\n --allow-private Allow private schematics to be run from the command line. Default to\n false.\n\n --dry-run Do not output anything, but instead just show what actions would be\n performed. Default to true if debug is also true.\n\n --force Force overwriting files that would otherwise be an error.\n\n --list-schematics List all schematics from the collection, by name. A collection name\n should be suffixed by a colon. Example: '@angular-devkit/schematics-cli:'.\n\n --no-interactive Disables interactive input prompts.\n\n --verbose Show more information.\n\n --help Show this message.\n\nAny additional option is passed to the Schematics depending on its schema.\n```\n\n# Examples\n\n1. Create a new NPM package that contains a blank schematic.\n\n```sh\n$ schematics blank \n```\n\n2. Walkthrough example that demonstrates how to build a schematic.\n\n```sh\n$ schematics schematic --name \n```\n\n\n# Getting Started With Schematics\n\nThis repository is a basic Schematic implementation that serves as a starting point to create and publish Schematics to NPM.\n\n### Testing\n\nTo test locally, install `@angular-devkit/schematics-cli` globally and use the `schematics` command line tool. That tool acts the same as the `generate` command of the Angular CLI, but also has a debug mode.\n\nCheck the documentation with\n\n```bash\nschematics --help\n```\n\n### Unit Testing\n\n`npm run test` will run the unit tests, using Jasmine as a runner and test framework.\n\n### Publishing\n\nTo publish, simply do:\n\n```bash\nnpm run build\nnpm publish\n```\n\nThat's it!\n\n\n# Schematics\n\n> A scaffolding library for the modern web.\n\n## Description\n\nSchematics are generators that transform an existing filesystem. They can create files, refactor existing files, or move files around.\n\nWhat distinguishes Schematics from other generators, such as Yeoman or Yarn Create, is that schematics are purely descriptive; no changes are applied to the actual filesystem until everything is ready to be committed. There is no side effect, by design, in Schematics.\n\n# Glossary\n\n| Term | Description |\n| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Schematics** | A generator that executes descriptive code without side effects on an existing file system. |\n| **Collection** | A list of schematics metadata. Schematics can be referred by name inside a collection. |\n| **Tool** | The code using the Schematics library. |\n| **Tree** | A staging area for changes, containing the original file system, and a list of changes to apply to it. |\n| **Rule** | A function that applies actions to a `Tree`. It returns a new `Tree` that will contain all transformations to be applied. |\n| **Source** | A function that creates an entirely new `Tree` from an empty filesystem. For example, a file source could read files from disk and create a Create Action for each of those. |\n| **Action** | An atomic operation to be validated and committed to a filesystem or a `Tree`. Actions are created by schematics. |\n| **Sink** | The final destination of all `Action`s. |\n| **Task** | A Task is a way to execute an external command or script in a schematic. A Task can be used to perform actions such as installing dependencies, running tests, or building a project. A Task is created by using the `SchematicContext` object and can be scheduled to run before or after the schematic `Tree` is applied. |\n\n# Tooling\n\nSchematics is a library, and does not work by itself. A [reference CLI](https://github.com/angular/angular-cli/blob/main/packages/angular_devkit/schematics_cli/bin/schematics.ts) is available on this repository, and is published on NPM at [@angular-devkit/schematics-cli](https://www.npmjs.com/package/@angular-devkit/schematics-cli). This document explains the library usage and the tooling API, but does not go into the tool implementation itself.\n\nThe tooling is responsible for the following tasks:\n\n1. Create the Schematic Engine, and pass in a Collection and Schematic loader.\n1. Understand and respect the Schematics metadata and dependencies between collections. Schematics can refer to dependencies, and it's the responsibility of the tool to honor those dependencies. The reference CLI uses NPM packages for its collections.\n1. Create the Options object. Options can be anything, but the schematics can specify a JSON Schema that should be respected. The reference CLI, for example, parses the arguments as a JSON object and validates it with the Schema specified by the collection.\n1. Schematics provides some JSON Schema formats for validation that tooling should add. These validate paths, html selectors and app names. Please check the reference CLI for how these can be added.\n1. Call the schematics with the original Tree. The tree should represent the initial state of the filesystem. The reference CLI uses the current directory for this.\n1. Create a Sink and commit the result of the schematics to the Sink. Many sinks are provided by the library; FileSystemSink and DryRunSink are examples.\n1. Output any logs propagated by the library, including debugging information.\n\nThe tooling API is composed of the following pieces:\n\n## Engine\n\nThe `SchematicEngine` is responsible for loading and constructing `Collection`s and `Schematics`. When creating an engine, the tooling provides an `EngineHost` interface that understands how to create a `CollectionDescription` from a name, and how to create a `SchematicDescription`.\n\n# Schematics (Generators)\n\nSchematics are generators and part of a `Collection`.\n\n## Collection\n\nA Collection is defined by a `collection.json` file (in the reference CLI). This JSON defines the following properties:\n\n| Prop Name | Type | Description |\n| ----------- | -------- | --------------------------- |\n| **name** | `string` | The name of the collection. |\n| **version** | `string` | Unused field. |\n\n## Schematic\n\n# Operators, Sources and Rules\n\nA `Source` is a generator of a `Tree`; it creates an entirely new root tree from nothing. A `Rule` is a transformation from one `Tree` to another. A `Schematic` (at the root) is a `Rule` that is normally applied on the filesystem.\n\n## Operators\n\n`FileOperator`s apply changes to a single `FileEntry` and return a new `FileEntry`. The result follows these rules:\n\n1. If the `FileEntry` returned is null, a `DeleteAction` will be added to the action list.\n1. If the path changed, a `RenameAction` will be added to the action list.\n1. If the content changed, an `OverwriteAction` will be added to the action list.\n\nIt is impossible to create files using a `FileOperator`.\n\n## Provided Operators\n\nThe Schematics library provides multiple `Operator` factories by default that cover basic use cases:\n\n| FileOperator | Description |\n| -------------------------------- | -------------------------------------------------------------------- |\n| `contentTemplate(options: T)` | Apply a content template (see the [Templating](#templating) section) |\n| `pathTemplate(options: T)` | Apply a path template (see the [Templating](#templating) section) |\n\n## Provided Sources\n\nThe Schematics library additionally provides multiple `Source` factories by default:\n\n| Source | Description |\n| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |\n| `empty()` | Creates a source that returns an empty `Tree`. |\n| `source(tree: Tree)` | Creates a `Source` that returns the `Tree` passed in as argument. |\n| `url(url: string)` | Loads a list of files from the given URL and returns a `Tree` with the files as `CreateAction` applied to an empty `Tree`. |\n| `apply(source: Source, rules: Rule[])` | Apply a list of `Rule`s to a source, and return the resulting `Source`. |\n\n## Provided Rules\n\nThe schematics library also provides `Rule` factories by default:\n\n| Rule | Description |\n| ------------------------------------------- | -------------------------------------------------------------------------------------- |\n| `noop()` | Returns the input `Tree` as is. |\n| `chain(rules: Rule[])` | Returns a `Rule` that's the concatenation of other `Rule`s. |\n| `forEach(op: FileOperator)` | Returns a `Rule` that applies an operator to every file of the input `Tree`. |\n| `move(root: string)` | Moves all the files from the input to a subdirectory. |\n| `merge(other: Tree)` | Merge the input `Tree` with the other `Tree`. |\n| `contentTemplate(options: T)` | Apply a content template (see the Template section) to the entire `Tree`. |\n| `pathTemplate(options: T)` | Apply a path template (see the Template section) to the entire `Tree`. |\n| `template(options: T)` | Apply both path and content templates (see the Template section) to the entire `Tree`. |\n| `filter(predicate: FilePredicate)` | Returns the input `Tree` with files that do not pass the `FilePredicate`. |\n\n# Templating\n\nAs referenced above, some functions are based upon a file templating system, which consists of path and content templating.\n\nThe system operates on placeholders defined inside files or their paths as loaded in the `Tree` and fills these in as defined in the following, using values passed into the `Rule` which applies the templating (i.e. `template(options: T)`).\n\n## Path Templating\n\n| Placeholder | Description |\n| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- |\n| `__variable__` | Replaced with the value of `variable`. |\n| `__variable@function__` | Replaced with the result of the call `function(variable)`. Can be chained to the left (`__variable@function1@function2__ ` etc). |\n\n## Content Templating\n\n| Placeholder | Description |\n| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |\n| `<%= expression %>` | Replaced with the result of the call of the given expression. This only supports direct expressions, no structural (for/if/...) JavaScript. |\n| `<%- expression %>` | Same as above, but the value of the result will be escaped for HTML when inserted (i.e. replacing '<' with '\\<') |\n| `<% inline code %>` | Inserts the given code into the template structure, allowing to insert structural JavaScript. |\n| `<%# text %>` | A comment, which gets entirely dropped. |\n\n# Examples\n\n## Simple\n\nAn example of a simple Schematics which creates a \"hello world\" file, using an option to determine its path:\n\n```typescript\nimport { Tree } from '@angular-devkit/schematics';\n\nexport default function MySchematic(options: any) {\n return (tree: Tree) => {\n tree.create(options.path + '/hi', 'Hello world!');\n return tree;\n };\n}\n```\n\nA few things from this example:\n\n1. The function receives the list of options from the tooling.\n1. It returns a [`Rule`](src/engine/interface.ts#L73), which is a transformation from a `Tree` to another `Tree`.\n\n## Templating\n\nA simplified example of a Schematics which creates a file containing a new Class, using an option to determine its name:\n\n```typescript\n// files/__name@dasherize__.ts\n\nexport class <%= classify(name) %> {\n}\n```\n\n```typescript\n// index.ts\n\nimport { strings } from '@angular-devkit/core';\nimport {\n Rule,\n SchematicContext,\n SchematicsException,\n Tree,\n apply,\n branchAndMerge,\n mergeWith,\n template,\n url,\n} from '@angular-devkit/schematics';\nimport { Schema as ClassOptions } from './schema';\n\nexport default function (options: ClassOptions): Rule {\n return (tree: Tree, context: SchematicContext) => {\n if (!options.name) {\n throw new SchematicsException('Option (name) is required.');\n }\n\n const templateSource = apply(url('./files'), [\n template({\n ...strings,\n ...options,\n }),\n ]);\n\n return branchAndMerge(mergeWith(templateSource));\n };\n}\n```\n\nAdditional things from this example:\n\n1. `strings` provides the used `dasherize` and `classify` functions, among others.\n1. The files are on-disk in the same root directory as the `index.ts` and loaded into a `Tree`.\n1. Then the `template` `Rule` fills in the specified templating placeholders. For this, it only knows about the variables and functions passed to it via the options-object.\n1. Finally, the resulting `Tree`, containing the new file, is merged with the existing files of the project which the Schematic is run on.\n\n\n# Angular CLI - The CLI tool for Angular.\n\nThe sources for this package are in the [Angular CLI](https://github.com/angular/angular-cli) repository. Please file issues and pull requests against that repository.\n\nUsage information and reference details can be found in repository [README](https://github.com/angular/angular-cli/blob/main/README.md) file.\n\n\n# `@angular/create`\n\n## Create an Angular CLI workspace\n\nScaffold an Angular CLI workspace without needing to install the Angular CLI globally. All of the [ng new](https://angular.dev/cli/new) options and features are supported.\n\n## Usage\n\n### npm\n\n```\nnpm init @angular@latest [project-name] -- [...options]\n```\n\n### yarn\n\n```\nyarn create @angular [project-name] [...options]\n```\n\n### pnpm\n\n```\npnpm create @angular [project-name] [...options]\n```\n\n### bun\n\n```\nbun create @angular [project-name] [...options]\n```\n\n\n# `@angular/pwa`\n\nThis is a [schematic](https://angular.dev/tools/cli/schematics) for adding\n[Progressive Web App](https://web.dev/progressive-web-apps/) support to an Angular project. Run the\nschematic with the [Angular CLI](https://angular.dev/tools/cli):\n\n```shell\nng add @angular/pwa --project \n```\n\nExecuting the command mentioned above will perform the following actions:\n\n1. Adds [`@angular/service-worker`](https://npmjs.com/@angular/service-worker) as a dependency to your project.\n1. Enables service worker builds in the Angular CLI.\n1. Imports and registers the service worker in the application module.\n1. Updates the `index.html` file to inlclude a link to add the [manifest.webmanifest](https://developer.mozilla.org/en-US/docs/Web/Manifest) file.\n1. Installs icon files to support the installed Progressive Web App (PWA).\n1. Creates the service worker configuration file called `ngsw-config.json`, specifying caching behaviors and other settings.\n\nSee [Getting started with service workers](https://angular.dev/ecosystem/service-workers/getting-started)\nfor more information.\n\n\n# Angular SSR\n\nRead the dev guide [here](https://angular.dev/guide/ssr).\n\n\n# Angular Compiler Webpack Plugin\n\nWebpack 5.x plugin for the Angular Ahead-of-Time compiler. The plugin also supports Angular JIT mode.\nWhen this plugin is used outside of the Angular CLI, the Ivy linker will also be needed to support\nthe usage of Angular libraries. An example configuration of the Babel-based Ivy linker is provided\nin the linker section. For additional information regarding the linker, please see: https://angular.dev/tools/libraries/creating-libraries#consuming-partial-ivy-code-outside-the-angular-cli\n\n## Usage\n\nIn your webpack config, add the following plugin and loader.\n\n```typescript\nimport { AngularWebpackPlugin } from '@ngtools/webpack';\n\nexports = {\n /* ... */\n module: {\n rules: [\n /* ... */\n {\n test: /\\.[jt]sx?$/,\n loader: '@ngtools/webpack',\n },\n ],\n },\n\n plugins: [\n new AngularWebpackPlugin({\n tsconfig: 'path/to/tsconfig.json',\n // ... other options as needed\n }),\n ],\n};\n```\n\nThe loader works with webpack plugin to compile the application's TypeScript. It is important to include both, and to not include any other TypeScript loader.\n\n## Options\n\n- `tsconfig` [default: `tsconfig.json`] - The path to the application's TypeScript Configuration file. In the `tsconfig.json`, you can pass options to the Angular Compiler with `angularCompilerOptions`. Relative paths will be resolved from the Webpack compilation's context.\n- `compilerOptions` [default: none] - Overrides options in the application's TypeScript Configuration file (`tsconfig.json`).\n- `jitMode` [default: `false`] - Enables JIT compilation and do not refactor the code to bootstrap. This replaces `templateUrl: \"string\"` with `template: require(\"string\")` (and similar for styles) to allow for webpack to properly link the resources.\n- `directTemplateLoading` [default: `true`] - Causes the plugin to load component templates (HTML) directly from the filesystem. This is more efficient if only using the `raw-loader` to load component templates. Do not enable this option if additional loaders are configured for component templates.\n- `fileReplacements` [default: none] - Allows replacing TypeScript files with other TypeScript files in the build. This option acts on fully resolved file paths.\n- `inlineStyleFileExtension` [default: none] - When set inline component styles will be processed by Webpack as files with the provided extension.\n\n## Ivy Linker\n\nThe Ivy linker can be setup by using the Webpack `babel-loader` package.\nIf not already installed, add the `babel-loader` package using your project's package manager.\nThen in your webpack config, add the `babel-loader` with the following configuration.\nIf the `babel-loader` is already present in your configuration, the linker plugin can be added to\nthe existing loader configuration as well.\nEnabling caching for the `babel-loader` is recommended to avoid reprocessing libraries on\nevery build.\nFor additional information regarding the `babel-loader` package, please see: https://github.com/babel/babel-loader/tree/main#readme\n\n```typescript\nimport linkerPlugin from '@angular/compiler-cli/linker/babel';\n\nexports = {\n /* ... */\n module: {\n rules: [\n /* ... */\n {\n test: /\\.[cm]?js$/,\n use: {\n loader: 'babel-loader',\n options: {\n cacheDirectory: true,\n compact: false,\n plugins: [linkerPlugin],\n },\n },\n },\n ],\n },\n};\n```\n\n\n# `/packages` Folder\n\nThis folder is the root of all defined packages in this repository.\n\nPackages that are marked as `private: true` will not be published to NPM.\n\nThis folder includes a directory for every scope in NPM, without the `@` sign. Then one folder\nper package, which contains the `package.json`.\n\n\n# @schematics/angular\n\nThis package contains a collection of [schematics](/packages/angular_devkit/schematics/README.md)\nfor generating an Angular application.\n\n## Schematics\n\n| Name | Description |\n| -------------- | ----------------------------------------------------------------------------------------------------- |\n| app-shell | Generates an app shell for running a server-side version of an app |\n| application | Generates a new basic app definition in the \"projects\" subfolder of the workspace |\n| class | Creates a new, generic class definition in the given project |\n| component | Creates a new, generic component definition in the given project |\n| directive | Creates a new, generic directive definition in the given project |\n| enum | Generates a new, generic enum definition in the given project |\n| guard | Generates a new, generic route guard definition in the given project |\n| interceptor | Creates a new, generic interceptor definition in the given project |\n| interface | Creates a new, generic interface definition in the given project |\n| library | Creates a new, generic library project in the current workspace |\n| module | Creates a new, generic NgModule definition in the given project |\n| ng-new | Creates a new project by combining the workspace and application schematics |\n| pipe | Creates a new, generic pipe definition in the given project |\n| resolver | Creates a new, generic resolver definition in the given project |\n| service | Creates a new, generic service definition in the given project |\n| service-worker | Pass this schematic to the \"run\" command to create a service worker |\n| web-worker | Creates a new, generic web worker definition in the given project |\n| workspace | Initializes an empty workspace and adds the necessary dependencies required by an Angular application |\n\n## Disclaimer\n\nWhile the schematics when executed via the Angular CLI and their associated options are considered stable, the programmatic APIs are not considered officially supported and are not subject to the breaking change guarantees of SemVer.\n\n\n## Update Package Group packages\n\n* `update-package-group-1@1.0.0` -> `update-package-group2@^1`\n* `update-package-group-2@1.0.0` -> `update-package-group1@1.0.0`\n----\n\n* `update-package-group-1@1.0.0` -> `update-package-group2@^1`\n* `update-package-group-2@1.1.0` -> `update-package-group1@1.0.0`\n----\n\n* `update-package-group-1@1.2.0` -> `update-package-group2@^2`\n* `update-package-group-2@2.0.0` -> `update-package-group1@^1`\n----\n"}