In this commit, the `ngServerMode` check is moved outside the RxJS `pipe()` to ensure that server-only logic is excluded from client bundles. Previously, the `tap()` operator and its closure were always included in the output, even though `ngServerMode` was false on the client and the side effect was never triggered.
By guarding the observable chain earlier, this reduces the RxJS stack frame depth, which simplifies debugging by avoiding unnecessary operator noise in client-side stack traces.
The resulting logic is also easier to reason about and avoids evaluating `HttpResponse` instances where not needed.
PR Close#62238
Previously these tests would run automatically when Angular DevTools lived in another repo. These files have continued to live here but have not been running automatically on each PR.
Now, these test files have been revived to run properly with our changes since the repo merge. This is a first step to reviving our e2e testing.
Next steps include writing cypress tests for new features like Injector Graph, Router tree, signals visualizations, etc.
PR Close#61972
This commit prevents lazy injection of the internal `ErrorHandler` from a destroyed injector, as it would result in another "destroyed injector" error.
PR Close#61886
In this commit, setting `window.history.scrollRestoration` is wrapped in a try-catch block to prevent `SecurityError` exceptions in restricted contexts such as:
- sandboxed iframes
- partially navigated or inactive windows
- test runners, extensions, or content previews
If an error occurs, a runtime warning with error code [2400] is logged to the console. This avoids breaking app initialization and improves cross-browser safety.
Unfortunately, it's not possible to perform any end-to-end testing of this fix.
PR Close#62186
Fixes that the logic recognizing initializer APIs didn't account for the expression being wrapped in an `as` expresion or in a parenthesized expression. This was already accounted for in the diagnostic so these changes align the behavior between them.
Fixes#62197.
PR Close#62203
Fixes that `getDeferBlocks` wasn't accounting for the case where a component might be injecting `ViewContainerRef`. When that happens, an additional wrapper is introduced that needs to be accounted for when traversing the tree.
Fixes#62047.
PR Close#62156
Removes the `google-closure-compiler` dependency that keeps getting updated by the bot, even though we don't actually use it.
PR Close#62206
PR Close#62210
docs: fix reference
Co-authored-by: Matthieu Riegler <kyro38@gmail.com>
docs: grammar fix
Co-authored-by: Jeremy Elbourn
docs: update docs reference
Co-authored-by: Andrew Scott <atscott01@gmail.com>
docs: update docs reference
Co-authored-by: Andrew Scott <atscott01@gmail.com>
docs: update docs reference
Co-authored-by: Andrew Scott <atscott01@gmail.com>
docs: update docs reference
Co-authored-by: Andrew Scott <atscott01@gmail.com>
docs: update route guard title
docs: update route guard types to table
docs: improve phrasing on activated route snapshot description
docs: improve comments to explain how route guard child works
docs: enhance route guards with more explainers and examples
PR Close#62104
Spec updates are in https://github.com/whatwg/html/pull/10919
For the most part, the updates revolve around the deferred commit
handling (with precommitHandler). Updates to redirect allow more
options. A committed promise now exists on the transition since commits
can be delayed. Tests were made zoneless for easier debugging and
timeouts were reduced.
PR Close#62017
Hybrid applications trigger a digest when `onMicrotaskEmpty` emits so
that the AngularJS app can run its lifecycle when the Angular app does. For
ZoneJS applications, this is effectively after every render/app tick. This change
updates the code to use `afterEveryRender` instead.
fixes#61640
PR Close#61660
Fixes the following issues with the logic in the unused imports migration that deals with trailing commas:
1. It was generating overlapping text ranges which can break internally.
2. It wasn't handling some cases that produce trailing commas.
PR Close#62118
This commit updates the global error listener to wrap the global ErrorEvent in a new Error with cause
if the error property is undefined.
fixes#62078
PR Close#62081
The value literal table listed tagged template strings as both supported and unsupported. The row under Unsupported literals was removed.
PR Close#62082
docs: update language block
Co-authored-by: Matthieu Riegler <kyro38@gmail.com>
docs: enhance redirects function docs
docs: fix future tense usage
docs: update phrasing to be present tense
docs: update redirect guides to use better phrasing and examples
docs: fix typo on code example
Co-authored-by: Andrew Scott <atscott01@gmail.com>
docs: fix typo in code example
Co-authored-by: Andrew Scott <atscott01@gmail.com>
docs: update syntax of code snippet
Co-authored-by: Andrew Scott <atscott01@gmail.com>
docs: update description on redirect function and api docs
PR Close#62005
In this commit, we request `APP_ID` outside the `onDestroy` callback because the injector might already be in a destroyed state when the callback runs.
PR Close#61885
Projected nodes were missing ssrId information and were skipping annotating template information, which caused templates to be destroyed and recreated rather than hydrated.
fixes: #50543
PR Close#62012
Due to a bug that is currently in progress of being resolved in the
`rules_js` toolchain (see:
https://github.com/aspect-build/rules_js/issues/362), we were seeing
subtle differences between `main` and PRs/local builds as RBE is a
strict sandbox environment while the normal linux/darwin sandbox isn't
necessarily.
This commit fixes the issue by avoiding the interop targets that don't
bring in the actual transitive node modules.
PR Close#62027
Temporarily updates the new Node loader to work with `zone.js` `.mjs`
files that are still ending up at runtime due to this package using
`ts_library`.
PR Close#61902
Due to `resource()` not retaining its value while there is a request in progress, the results list flickers. The new `searchResults` signal retains that previous value until the request is completed.
PR Close#61935
Due to `resource()` not retaining its value while there is a request in progress, the results list flickers. The new `searchResults` signal retains that previous value until the request is completed.
PR Close#61935
This ensures that test functions with arguments (e.g. `it.each` in jest)
are forwarded to the test function. This does not apply to jasmine,
which assumes the only arguments needed would be the `done` function.
fixes#61717
PR Close#61755
The reveal answer button accidentally loads files into the embedded
editor that aren't properly relativized. This ends up switching the
currently open file to a different file, unexpectedly.
In addition, due to the incorrect paths, files like `favicon.ico` end up
being loaded in the embedded editor; resulting in a bad experience as
the images are shown as plain text.
PR Close#61925
when marked for traversal the reactive context has to be set to null to avoid inheriting the reactive context of the parent component
PR Closes#61662
PR Close#61663
This commit configures Renovate to automatically apply 'target' labels to pull requests based on their base branch.
- `main` branch will get `target: minor` label.
- Other branches will get `target: patch` label.
PR Close#61894
Migrates the partial compliance tests to `rules_js`. Also as part of
this, we re-enable RBE to see if that fixed the issues, or in case
they are already resolved from the RBE side.
PR Close#61895
For the `rules_js` migration, we are facing the problem where
our current Angular code is shipped as ESM, but we aren't fully
there yet with fully compliant strict ESM during development.
That is because we lack explicit import extensions, and it's also a
different story how this would work in Google3, if we were to add them.
In addition, we cross-import from our packages using npm module names.
This works well for TS, for ESBuild because those can respect path
mappings— but at runtime, when executing native `jasmine_test`'s— such
mappings aren't respected. The options here are:
- avoid module imports in the repo (impossible; undesired)
- use pre-bundling of all NodeJS execution involving npm package code
(slower, extra build action cost)
- wire up a simple NodeJS loader (supported via official APIs) to simply
account for our cases (preferred and similar to what we experimented
with for the last year(s); and worked well)
This commit implements the last option and allows for an easy migration
to `rules_js`, and also is pretty reasonable. Long-term we can resolve
the extension problem if we e.g. migrate to real explicit extensions + a
proper TS module resolution like e.g. `nodenext`.
PR Close#61895
We should remove the `onDestroy` listener once subscription is unsubscribed because components might not be destroyed yet, but they still would capture subscribers.
PR Close#61882
Update the bazel query for finding all releasable packages to look for all targets with the name
`npm_package` that contain the expected tag.
PR Close#61879
PR Close#61862
The bazel npm package is no longer needed and currently breaks
as we started using a 1P pnpm linked package that would otherwise
end up being pulled into this legacy rule.
PR Close#61862
This commit migrates the remaining pieces of `compiler-cli` to
`ts_project`. This involves a few more things during migration:
- the `ng_module` ngc_wrapped rule broke as part of this change, so we
switched it to `ts_project` too. This logic is soon gone anyway.
- we needed an extra pnpm "package.json" for the linker babel test. This test is
loading from the real compiler-cli npm package. Babel needs a real
node module for this, so this solution seems reasonable. It may be
worth exploring in the future to move this test into an integration
test though.
- the older integrationtest in compiler-cli is removed as the coverage
is much better with the compliance test suite and this test.
PR Close#61862
This commit unregisters the `onDestroy` listener when `destroy()` is called on the `ResourceImpl`. This prevents memory leaks and ensures that the resource reference is not captured in the destroy callback after it has already been destroyed.
PR Close#61870
In this commit, we mark the `SwPush` and `SwUpdate` classes as root providers. As a result, they are no longer statically referenced in the `provideServiceWorker` providers list, which previously forced them to be explicitly bundled into the main file. These classes might never be used—some consumers may use the service worker only for prefetching and caching assets.
Practically speaking, even if a user injects the `SwPush` class without calling `provideServiceWorker()`, it would result in a DI error because the communication channel dependency is not available. There is no practical reason to keep these classes as non-root providers or to reference them explicitly.
Currently, some users work around this by using `patch-package` to modify the service worker code and remove these classes from the providers list.
PR Close#61670
Previously this would throw an error on the assertLView when we try to discover the templateLView.
Now this properly returns null for the template consumer and continues discovering other effects on the injector.
PR Close#60772
Adds fix directly for `takeUntilDestroyed` to unsubscribe when already
destroyed instead of putting
synchronous behavior on `DestroyRef.onDestroyed` callback as in #58008fixes#54527
PR Close#61847
Change the command to execute the migration, because the command stated in the previous version results in the error "Cannot find migration 'control-flow-migration' in '@angular/core'.". The new command is more in line with the docs of other migrations.
PR Close#61816
Refactor createSignal to return a tuple instead of a signal getter. createSignalTuple will be removed in a follow up pr once createSignalTuple usages in google3 are migrated to createSignal.
PR Close#61705
The observable terminates immediately when `error` is called, and no further emissions or completion notifications occur. Thus, we have to remove the listener in both the `error` and `complete` notifications.
PR Close#61596
Previously, multiple simultaneous calls to `checkForUpdate()` could result in redundant
fetches and hashing of the update manifest, leading to unnecessary network and CPU usage.
This change introduces a mechanism to track an in-progress update check using a cached
promise (`ongoingCheckForUpdate`). Subsequent calls to `checkForUpdate()` while a check
is in progress will return the same promise instead of triggering a new request.
Once the check completes (successfully or not), the cached promise is cleared,
allowing future update checks to proceed normally.
This improves efficiency and prevents overlapping update logic in applications that
may invoke `checkForUpdate()` from multiple sources (e.g. polling, manual triggers).
PR Close#61443
The code editor tooltip exhibits some weird bug when there is a margin applied. The root issue is unknown but at least it improves the current situation.
fixes#60923
PR Close#61782
This update ensures that the service worker can handle range requests, allowing video seeking to work correctly when videos are delivered by the service worker.
PR Close#60029
This ensures that the new optimization rule, and also adev (when we
complete migrating it to `rules_js`) can use the latest compiler-cli
version from HEAD.
PR Close#61810
PR Close#61830
When the expression parser consumes tokens inside a parenthesized expression, it looks for valid tokens until it hits and invalid one or a closing paren. If it finds an invalid token, it reports and error and tries to recover until it finds a closing paren. The problem is that in such cases, it would produce the `ParenthesizedExpression` and continue parsing **from** from the closing paren which would then produce more errors that add noise to the output and result in an incorrect representation of the user's code. E.g. `foo((event.target as HTMLElement).value)` would be recovered to `foo((event.target)).value` instead of `foo((event.target).value)`.
These changes resolve the issue by skipping over the closing paren at the recovery point.
Fixes#61792.
PR Close#61815
Commit 3e70d64 introduced cdk version 20.0.0-rc2 which introduced a change to how the cdk virtual scroll sets some internal state.
Previously in DevTools we were using a computed incorrectly to respond to changes in the directive forest and apply them to the underlying datasource. With the change to the CDK shown above, this incorrect usage caused us to attempt to update underlying signals in the virtual scroll directive while within a computed callback, throwing an error.
This commit corrects our usage by swapping from a computed to an effect, allowing the underlying signals in the scroll directive to be updated without error.
PR Close#61812
When defer blocks have a reference-based trigger without a parameter, we infer it from the placeholder block. This requires some validations like ensuring that there's only one element in the placeholder. The validations are currently implemented at the parser level which can affect tools like linters that need to pass `preserveWhitespaces: true` in order to get accurate source mappings.
These changes move the validations into the template type checker so that they still get flagged, but much later in the process. Moving them over involves a bit more work, because the template type checker also sets `preserveWhitespaces: true`.
Fixes#61725.
PR Close#61747
This commit updates runtime logic to produce an error when there are some `@defer` blocks with `hydrate` triggers, but the incremental hydration is not enabled via `withIncrementalHydration()`. Previously the check was only detecting the case when `withIncrementalHydration()` is present on the server, but missing on the client. With the change in this commit, the check would be performed on the server as well.
PR Close#61741
Follow-up to #61674 where we were leaving behind some whitespace, e.g. `[One, Two, Three]` would turn into `[One ]`. These changes only preserve the whitespace if the node is preceded by a newline.
This wasn't caught by tests, because they were stripping away whitespaces before asserting. I've also reworked the tests to be sensitive to formatting changes.
PR Close#61698
Updates the current list of DevTools reviewers to make a few small changes.
1. Adds `hawkgs` and `milomg`.
2. Removes the leading `~` from `JeanMeche` to include him in automatic review requests.
3. Adds `jkrems` for additional Googler coverage in automatic review requests.
4. Removes `mgechev` and `MarkTechson` who haven't been involved in daily DevTools development for a while.
5. Adds the leading `~` to `devversion` and `josephperrott` to remove them from automatic review requests while leaving them with access for "break glass" situations.
Note that the leading `~` means that the individual may approve PRs and satisfy the group's requirement, but PullApprove will not automatically request a review from them. See https://v3-docs.pullapprove.com/config/reviewers/#reviewers-that-dont-want-review-requests.
PR Close#61709
Re-exports the `FileSystem` type since it's used by some tsurge migrations and because internally the barrel export from `ngtsc/file_system` is removed.
PR Close#61697
We are dropping the custom ESBuild and Terser pipeline from dev-infra
and instead leverage the Angular CLI directly. This commit adjusts
the benchmarks to use this new rule.
Instead of dev-infra maintaining a custom ESBuild + Terser pipeline that
tries to emulate the Angular CLI, we are switching the bundling core
tests to a new rule that really leverages the Angular CLI.
This involves some file renames and small adjustments. In addition, we
leverage the updated symbol tracking rule to output new goldens that can
work with multiple bundle files (as generated by the Angular CLI;
especially with defer and its "lazy" chunks).
Since we are going to replace our `app_bundle` rule (custom ESBuild +
Terser pipeline) with the real Angular CLI where shared/lazy/common
chunks may exist, we need to update the symbol extractor to support
multiple files.
We could have just merged all symbols, but this commit tries to do
better by detecting what symbols are loaded eagerly vs. lazily. This
will be very useful for e.g. defer tests or other lazy features we are
introducing in the feature.
The `app_bundle` rule does not work after the migration of
`packages/compiler` to `ts_project` because the `.mjs` extensions are
now missing in the non npm-package output.
This causes runtime errors as `.js` is not recognized as ESM. Switching
to the real npm package for usage, fixes this issue.
Currently when linking the `@angular/compiler-cli` package, the peer
dependency to `compiler` is not resolved and we are trying to make the
compiler dependency available via `data`. This is unidiomatic and
brittle. This commit fixes this.
Compiler now would have `.js` files. Those aren't picked up as ESM,
unless we install the `package.json` with `type: module`. Sounds great
on paper, but doesn't work in reality because the way the compiler
packages are available to `api-gen/` is via the old `rules_nodejs`
linker, so the `packages/package.json` wouldn't work; nor do the
`package.json`s of the e.g. compiler-cli package work- because those
already contain the `exports` of the built npm package.
We fix this in a much more reasonable way, and the whole module
resolution problem by leveraging the pnpm linking here. This works as
expected.
Fixes a typo in the "Lazily loaded components" section of the define-routes.md guide.
The path for the home-page component was incorrectly written as ',' instead of ''.
PR Close#61740
In this commit, we switch from using the `isPlatformServer` runtime call to the `ngServerMode`.
Note: constructors haven't been touched in order to prevent any breaking changes for the public API.
PR Close#59496
Replaces the `propertyInterpolateX` instructions with calls to `property` and the `interpolate` helper. This allows us to drop the dedicated interpolation instructions and simplify the runtime for future work.
PR Close#61639
Updates the `ɵɵinterpolate` instruction so it doesn't call into `interpolation1` under the hood since it requires a prefix/suffix and we know there isn't one.
PR Close#61639
Replaces the `classMapInterpolateX` instructions with `classMap` plus a call to `interpolate` in order to simplify the runtime. The only difference between `classMapInterpolateX` and `classMap` was that the former passes `keyValueArraySet` into `checkStylingMap` while the latter passes `classKeyValueArraySet`. This doesn't appear to matter, because the interpolation instructions always have a string value which means that the function is never called.
PR Close#61639
Replaces the `styleMapInterpolateX` instructions with the existing `styleMap` and a passed-in interpolated value in order to simplify the runtime.
PR Close#61639
The hardcoded config was introduced because suppressing the diagnostic
via `extendedDiagnostics` in the TS config was unreliable in google3.
This has since been fixed and the workaround is no longer needed.
PR Close#61622
Disables creation of the esbuild meta.json file, which is not utilized in the build process. This streamlines the output and avoids generating unused artifacts.
PR Close#61636
Prevents esbuild generated metadata files from being included in build artifacts. This reduces package size and avoids shipping unnecessary internal build data.
PR Close#61636
This commit removes the direct dependency on TypeScript within the linker, addressing a performance overhead that was adding between 500ms to 1s to compilation times for applications.
The primary cause of this overhead was the linker's direct reliance on TypeScript's which was caused by importing from barrel files. While convenient, barrel files are detrimental to code splitting and code motion. They force the bundling of all exported modules, even if only a subset is actually used.
By removing the usage of this barrel file and restructuring the imports to be more granular, we can avoid unnecessary TypeScript imports.
Furthermore, TypeScript has now been changed to an optional peer dependency as using only the linker does not require TypeScript.
(cherry picked from commit 7cf2425fb5)
PR Close#61635
An initial guide to use the experimental unit testing system with the
vitest runner has been added. This includes setup instructions for switching
from the karma/jasmine based system.
Additional content for configuration and potential migration of existing
projects may be added in future changes.
PR Close#61483
This prevents `core/testing` from throwing an error if ZoneJS is present
but does not patch the test FW APIs such that `fakeAsync` works
automatically. For example, there is currently no patching of the vitest
APIs, so if you try to use Vitest with Zone on the page, it will throw.
PR Close#61628
In this commit, we check whether the application is destroyed before calling `serviceWorker.register(...)`. We should not register the worker because other resources will not be available.
PR Close#61101
When the resource is loading after reloading from the error state reading `Resource.value()` would return the default value instead of throwing an error.
This change prevents `Resource.hasValue()` from throwing an error in such a case.
PR Close#61441
`Resource.error` used to return `unknown`. Now it's `Error | undefined`.
For non-`Error` types they are encapsulated with the `Error` type.
PR Close#61441
The observable terminates immediately when `error` is called, and no further emissions or completion notifications occur. Thus, we have to remove the `abort` listener in both the `error` and `complete` notifications.
PR Close#58306
Updates the `bindingUpdated` function to handle `NO_CHANGE` instead of throwing. This will allow us to reuse instructions across more cases.
PR Close#61557
Replaces the attribute interpolation instructions with `attribute` plus the new `interpolateX` instruction. This allows to reduce our overall instruction footprint.
PR Close#61557
Adds the new `interpolate*` instructions that can be passed into other instructions and used to replace our existing flavors of interpolations.
PR Close#61557
When passing bindings as arguments or storing them before use in
`createComponent`, it's handy to be able to reference this type.
The current workaround is to use `ReturnType<typeof inputBinding>`.
PR Close#61351
Streams left in a pending state (due to `break` without cancel) may continue consuming or holding onto data behind the scenes. Calling `reader.cancel()` allows the browser or the underlying system to release any network or memory resources associated with the stream.
PR Close#61528
This ensures that `TestBed.tick` updates any components created with
`TestBed.createComponent`, regardless of whether autoDetectChanges is
on.
PR Close#61382
In other parts of the code, calls to the `assertInInjectionContext` function are guarded with `ngDevMode`. This change aligns these parts of the code with other implementations that drop such assertions in production.
PR Close#61564
Currently we construct the HMR replacement URL inline by calling into the native `URL` constructor. This can cause conflicts with user code that defines a symbol called `URL`.
These changes resolve the issue by moving the URL construction into a separate function. This has a secondary benefit of making the generated code easier to follow and allowing us to update the URL without changing the compiled code.
Fixes#61517.
PR Close#61550
In other parts of the code, calls to the `assertInInjectionContext` function are guarded with `ngDevMode`. This change aligns these parts of the code with other implementations that drop such assertions in production.
PR Close#61560
enforce content to be fluid until a specific max width, and rollback breakpoints to be applied when 1430px is the current win size
as widths between 1430px and 1431px will be broken
PR Close#61384
The code was not compatible with property renaming so it was always
using _lView. This didn't matter because they're always the same for the
only place the function is used. Casting to any would fix the
renaming problem but introduce a risk of getting "broken" by a refactor
that changes the private variable name. This change removes the
private member access entirely.
PR Close#60918
This change ensures that prior results for all files are retained even when
a request is made such that we only need a shim for a single file. Prior
to this change, any prior results that were not part of the request were discarded.
PR Close#61487
Avoids duplication of the `FactoryTarget` enums. This is necessary
now because we are exposing the previously deeply-imported JIT facade
now via the exports; and the typing integration tests surface a type
conflict due to the different duplicated enums.
PR Close#61476
These helpers are often imported by various tests throughout the
repository, but the helpers aren't exported/exposed from the public
entry-point; even though they confusingly reside in there.
This commit fixes this, and moves the helpers into
`packages/private/testing`. This is a preparation for the `ts_project`
migration where we don't want to leverage deep imports between packages.
PR Close#61476
Use an unstamped version of the compiler when it runs in `ng_project` as it will get stamped appropriately
whenever the generated code gets stamped after its usage."
PR Close#61479
Not sure what changed overnight, but Renovate is now committing .npmrc files that we didn't generate.
Example: https://github.com/angular/angular/pull/61492/files
We should revisit this once we transition away from Yarn.
PR Close#61494
This commit exposes the experimental enableProfiling() API that
enables Angular integration with the Chrome DevTools performance
panel. Previously this integration was exposed on the ng. namespace
only but there are legitimate cases where developers might want to
expose the integration earlier (ex.: bootstrap profiling).
PR Close#61465
Our intention was to remove TestBed.flushEffects() in Angular v20
as it was a developer preview API that doesn't need to follow our
deprecation policy. It turned out, though, that the angular.dev
documentation wasn't displaying the @developerPreview annotation
properly so some of the developers might have been unaware of the
non-stable nature of this API.
This commits re-introduces the TestBed.flushEffects() API. This
API call will delegate to TestBed.tick().
PR Close#61462
Instead of disabling sandbox/workers for every action; which also could
slow-down development turnaround significantly, the flag should only
disable sandboxing for the test actions; allowing for e.g. DevTools to
connect to them, even if they are inside the sandbox.
Arguably, this strategy isn't seemingly necessary in all environments,
but given that we enable network sandboxing in this repo, it seems
reasonable. Ideally we'd also expose `_debug` targets for e.g. Node
tests that have the proper no-sandbox, or requires-network tag.
PR Close#61468
Currently, `yarn ng-dev misc update-generated-files` attempts to update 67 targets, but only 4 actually require updating. Running the full script causes Renovate to slow down significantly, adding around 7 minutes to the process. By replacing it with individual update commands for just the necessary targets, we improve performance and reduce Renovate’s runtime considerably.
PR Close#61467
After nearly a decade of existence, there are 0 uses of
`autoDetectChanges(false)` internally. All uses of
`autoDetectChanges(true)` can be migrated directly to
`autoDetectChanges()` instead.
PR Close#61429
Adds `__PURE__` annotations to non-default `new` expressions to enable tree-shaking, even if they are not referenced. These variables are not dropped when Angular is imported from a module that has `sideEffects` set to `true`.
PR Close#61452
Since the duplication root-cause was solved by the previous commit, we
can revert/drop the logic that was added back then to overcome this
problem with Tsurge.
PR Close#61421
Currently there can be cases, exlusively in 3P, where multiple tsconfig
projects have overlap of source files. This is the default setup of new
CLI applications as well.
When this is the case, Tsurge will treat each tsconfig as an isolated
compilation unit (given the concepts and mental model to support
scalable batching). This is wrong though, and the same `.ts` source file
can appear in two migration invocations; resulting in duplicate
replacements or analysis (depending on the migration).
We've worked around this problem in the past by deduplicating
replacements, or migrating to an ID-based approach with natural
deduplication. This worked, but it's just working around the root cause.
This commit attempts to fix the root cause by adjusting Tsurge to ensure
that no source file ever appears in two compilation units. This is
naively achieved by not adding a source file to a migration unit, if it
was part of a previous one. This is expected to be fine given the nature
of Tsurge migrations that are built to operate on isolated pieces
anyway— so it shouldn't be problematic if e.g. `app.component.ts` ends
up being part of the test tsconfig compilation unit (we avoid this order
though by visiting build targets first).
PR Close#61421
Migrates `packages/core/schematics` to `ts_project`. As part of this,
this commit cleans up some of the mixed module types and tsconfigs in
the folder. A single tsconfig (and it's test variant) are now used.
For the shipped schematics, we explicitly use the `.cjs` extension, so
that the bundles are properly recognized as CommonJS; even if they are
part of the `type: module` `@angular/core` package.
The `package.json` with `type: commonjs` is removed from
`packages/core/schematics` as it's no longer needed given the explicit
extension & caused issues as schematics are compiled with ESM but are
only later bundled for shipping & some tests as ESM.
PR Close#61414
As we migrate more and more code to `ts_project`, we are ending up with
`.js` file extensions (ts_library did generate `.mjs` magically).
Since we don't want to get into the business of migrating
`nodejs_binary` targets at this point (in some cases we might)— we
should support pointing to such files.
PR Close#61414
Fixes the `update_all_goldens` script which was throwing, because the query command was also capturing the call into yarn and Bazel which in turn caused it to throw an error. I've also added some validation for the number of targets.
PR Close#61407
* Fixes that the symbol extractor approval script was broken after some recent build changes.
* Fixes the `run_all_symbol_extractor_tests` script which wasn't resolving any targets, because the rule name changed.
PR Close#61407
On `19.2` we pass an undefined value to the text-field.
But more generaly, the CVA should protect itself if it doesn't recieve an `undefined` value.
fixes#61299
PR Close#61300
The `getBaseHref` method is called several times per request and currently queries through the entire document. We can speed it up by taking advantage of the fact that the `<base>` can only be a direct child of the `<head>` and is usually defined towards the beginning. Below are some benchmarks for a "Hello world" app before and after this change.
### Before:
```
Running 60s test @ http://localhost:4202
100 connections with 10 pipelining factor
┌─────────┬────────┬────────┬────────┬────────┬───────────┬──────────┬─────────┐
│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │
├─────────┼────────┼────────┼────────┼────────┼───────────┼──────────┼─────────┤
│ Latency │ 568 ms │ 853 ms │ 901 ms │ 904 ms │ 866.58 ms │ 437.6 ms │ 9915 ms │
└─────────┴────────┴────────┴────────┴────────┴───────────┴──────────┴─────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat │ 1% │ 2.5% │ 50% │ 97.5% │ Avg │ Stdev │ Min │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec │ 490 │ 826 │ 1,006 │ 1,643 │ 1,129.3 │ 234.69 │ 490 │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 10.4 MB │ 17.4 MB │ 21.3 MB │ 34.7 MB │ 23.9 MB │ 4.96 MB │ 10.3 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘
Req/Bytes counts sampled once per second.
# of samples: 60
69k requests in 60.04s, 1.43 GB read
90 errors (90 timeouts)
```
### After
```
Running 60s test @ http://localhost:4202
100 connections with 10 pipelining factor
┌─────────┬────────┬────────┬────────┬─────────┬───────────┬───────────┬─────────┐
│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │
├─────────┼────────┼────────┼────────┼─────────┼───────────┼───────────┼─────────┤
│ Latency │ 471 ms │ 831 ms │ 889 ms │ 1668 ms │ 835.91 ms │ 467.89 ms │ 9720 ms │
└─────────┴────────┴────────┴────────┴─────────┴───────────┴───────────┴─────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬──────────┬────────┬─────────┐
│ Stat │ 1% │ 2.5% │ 50% │ 97.5% │ Avg │ Stdev │ Min │
├───────────┼─────────┼─────────┼─────────┼─────────┼──────────┼────────┼─────────┤
│ Req/Sec │ 390 │ 860 │ 1,145 │ 1,572 │ 1,156.77 │ 222.65 │ 390 │
├───────────┼─────────┼─────────┼─────────┼─────────┼──────────┼────────┼─────────┤
│ Bytes/Sec │ 8.24 MB │ 18.2 MB │ 24.2 MB │ 33.2 MB │ 24.4 MB │ 4.7 MB │ 8.24 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴──────────┴────────┴─────────┘
Req/Bytes counts sampled once per second.
# of samples: 60
71k requests in 60.03s, 1.47 GB read
140 errors (140 timeouts)
```
PR Close#61392
This prevents `core/testing` from throwing an error if ZoneJS is present
but does not patch the test FW APIs such that `fakeAsync` works
automatically. For example, there is currently no patching of the vitest
APIs, so if you try to use Vitest with Zone on the page, it will throw.
PR Close#61376
There were a myriad of problems when using the type: 'cli' for a
tutorial:
* Editor component would flicker the non-cli version first since that
was the default value. Fixed by not showing anything until type is
available
* Editor component still rendered a split screen when there was no
preview. Fixed
* Project initialization was incorrect because the terminal would appear
to be available but really didn't work until dependencies were done
installing. Fixed by sharing initialization with regular project init
and piping the install output to the interactive terminal
* Terminals would not work when going from type: 'cli' to another or
vice versa. This is because the element instance of a terminal cannot
change once it is opened. Fixed by dispoing and recreating terminals
when the element changes
PR Close#61246
This commit implements several enhancements to the adev docs update workflow pipeline:
- **Unify actions:** Merge the workflows into a single one.
- **Optimize Git cloning:** Clone the repo with `--depth=0` only once per push instead of 2 times.
- **Prevent concurrent runs:** Implement concurrency control to automatically cancel in-progress workflow runs for the same branch, ensuring only the latest commit is processed.
PR Close#61253
All entries of the `@angular/platform-browser-dynamic` package are now deprecated.
We now recommend using the `@angular/platform-browser` package instead.
In case a JIT application/testing environment is complaining about missing the compiler also add `import '@angular/compiler'`
DEPRECATED: All entries of the `@angular/platform-browser-dynamic`
PR Close#61043
The Angular class metadata emit structure does not support the use of
private fields. If the class metadata emit is enabled and an ECMAScript
private (i.e., `#` prefixed) member contains a decorator, the member will
now be excluded from the emitting `setClassMetadata` call. This prevents
runtime errors due to invalid syntax.
PR Close#61227
The release process overview is out of date and does not accurately reflect section headers. It's not worth the maintenance effort of keeping it in sync with the rest of the doc.
Added a step 0 to check if there's actually anything to release, reusing the command from later in the doc.
Also makes a few random small corrections to reflect the new release process.
PR Close#60892
This commit adds an import to the `ng_dev_mode.ts` file that augments
`global` to have types for `ngDevMode`.
Notably this change is currently not needed because the file is loaded
by `ts_library` through `tsconfig#files`— but in a separate PR we are
switching the target to `ts_project` which no longer loads all Bazel
dependency files via `tsconfig#files`; resulting in the ambient types no
longer magically being available.
PR Close#61365
Return types for exported functions from the router package have now been
added. This provides preparation for the inclusion of additional linting
rules which will eventually enforce the presence of return types for
functions. It also improves readability and type correctness within the
code.
PR Close#61310
fix new global layout issues, and make other pages adhere to the new centered layout like cli ref page, cli ref details, api ref details pages
PR Close#61256
As we roll out more PRs that migrate to `ts_project`, we need to make
sure that we don't break existing `tsec` targets. This PR copies the
original `tsec` Starlark code and adjusts it to work with the interop.
Note that we don't patch as this would unnecessarily complicate this
file that only exists during migration. Long-term, after migration, we
either need to consider switching to the new ESLint plugin that is being
worked on (I'm in contact with the team), or we send a CL to update the
Tsec Starlark code to keep our changes minimal and avoid scope increase.
PR Close#61335
Supports arbitrary stats/metrics in Tsurge. This will make
complex analysis easier as we aren't bound to just `Record<string,
number>` counters.
PR Close#61272
The compiler wasn't handling `@let` declarations placed inside i18n blocks. The problem is that `assignI18nSlotDependencies` phase assigns the `target` of i18n ops much earlier than the `@let` optimization. If the `@let` ends up getting optimized because it isn't used in any child views, the pointer in the i18n instruction becomes invalid. This hadn't surfaced so far, because we didn't optimize `declareLet` ops, however once we do, we start hitting assertions that the optimized `declareLet` isn't used anywhere.
These changes resolve the issue by moving the i18n phases after the `@let` optimization.
PR Close#60512
We have some code that avoids `storeLet` calls for declarations only used in the same view, however we didn't previously remove the corresponding `declareLet` calls, because of the following case:
```
@let foo = something$ | async; <!-- First in the template -->
{{foo}}
```
Here we need a `TNode` (created by `declareLet`) in order for DI to work correctly. Since this is only required when using pipes, we can optimize away expressions that do not have pipes.
PR Close#60512
As part of the Bazel toolchain migration we noticed that implicit types
generated by the TypeScript compiler sometimes end up referencing types
from other packages (i.e. cross-package imports).
These imports currently work just because the Bazel `ts_library` and
`ng_module` rules automatically inserted a `<amd-module
name="@angular/x" />` into `.d.ts` of packages. This helped TS figure
out how to import a given file. Notably this is custom logic that is not
occuring in vanilla TS or Angular compilations—so we will drop this
magic as part of the toolchain cleanup!
To improve code quality and keep the existing behavior working, we are
doing the following:
- adding a lint rule that reduces the risk of such imports breaking. The
failure scenario without the rule is that API goldens show unexpected
diffs, and types might be duplicated in a different package!
- keeping the `<amd-module` headers, but we manually insert them into
the package entry-points. This should ensure we don't regress
anywhere; while we also improved general safety around this above.
Long-term, isolated declarations or a lint rule from eslint-typescript
can make this even more robust.
PR Close#61312
Avoid pnpm auto-installing peer dependencies. We want to be explicit about our versions used for peer dependencies, avoiding potential mismatches. In addition, it ensures we can continue to rely on peer dependency placeholders substituted via Bazel.
PR Close#61295
In the event of an invalid `schemas` field for an Angular module, an
empty schema array will now be used instead of a fatal error occurring.
A build will still fail in this case with the error reported as a
diagnostic. However, for the language service, this allows the module
to exist in the compiler registry and prevents cascading diagnostics
within an IDE due to "missing" modules/components. The originating
schema related errors will still be reported in the IDE.
PR Close#61220
take the full width of the page for all the pages that use docs-viewer, also reserve an area for table of contents on-demand
Resolves: #52648
PR Close#58831
This aligns with how angular/components marks their hidden APIs.
`@nodoc` has been broken since the switch to adev, this change should
properly hide the APIs again.
PR Close#61194
Migrates `manual_api_docs` to `rules_js`. Since compiler CLI is ESM
compiled but doesn't have extensions, we can either bundle or simply use
the dependency as type only. This is easier and sufficient for this
use-case.
PR Close#61181
Renovate temporarily modifies the `.npmrc` file during its operations and reverts these changes afterward. However, during `postUpgradeTasks`, the non reverted `.npmrc` will lead to errors when running `yarn bazel sync --only=repo`
See: https://github.com/renovatebot/renovate/discussions/14897
PR Close#61239
Updates the name which accidentally remained unchanged from when I
copied it from the CLI help script
Also marks the PR for merge immediately. The caretaker can sanity check
it, approve it, and merge it.
PR Close#61195
Limits automated cross-repo updates to only follow the 'next' tag when operating on the main branch. This helps avoid unintended updates from other tags and ensures a controlled release process.
PR Close#61215
We don't need this tooling anymore because we are already validating
that there are no circular dependencies via the `ng-dev` tooling that
checks `.ts` files directly.
Also these tests never actually failed to my knowledge.
PR Close#61197
Replaces incorrect use of GitHub Actions expression syntax `${{CURRENT_BRANCH }}` inside a run block with proper bash variablesyntax `$CURRENT_BRANCH`, preventing 'Unrecognized named-value' errors.
PR Close#61212
This workflow addresses a limitation with Renovate's behavior in fork mode. Renovate does not automatically sync non-default branches in forked repositories.
This workflow automates syncing forked non-default branches with their upstream counterparts. This ensures Renovate can detect and apply updates to these branches, maintaining up-to-date dependencies across all relevant branches.
PR Close#61201
The `RouterLink` href does not depend on the state of the router unless
it uses the `fragment` or `queryParams`. This doesn't bother
unsubscribing from the events if the inputs change in a way to no longer
depend on those values since inputs changing is quite rare (and even
more rare for query params handling or preserveFragment to change).
PR Close#60875
This commit updates the method of setting the href attribute on
`RouterLink` to use built in host binding rather than custom attribute
setting and sanitization. The advantage here would be automatic handling
of the sanitization and avoiding of writing the same value to the DOM
that we had before.
This change does mean that we _always_ write to the href attribute where
before we only wrote to it when the elemnt was known to support `href`.
That said, the implementation attempts to retain behavior that is as
close as possible: the original value of `href` is used and never updated.
PR Close#60875
The `false` behavior has existed for a long time but hasn't really
been documented. It's also not _quite_ what the browser would do.
Finally, the page explicitly discourages the implicit `false` way
of preventing default. Biggest motivation (beyond code clarity) are
potential footguns like `(click)="myProp=x()"` which happens to prevent
default behavior iff `x()` happens to return `false`.
Fixes https://github.com/angular/angular.io/issues/2568
PR Close#61184
Dependency updates can no longer be cherry-picked due to hash changes in Aspect lock files. This commit enables Renovate to run directly on the `main` and `20.0.x` branches.
PR Close#61160
Other code may depend on `ngServerMode` and it might have been set
globally / via a bundler. Forcing it to `undefined` in those situations
can lead to hard debug issues where the only symptom is that "suddenly"
browser-specific code paths run on the server and (obviously) break.
PR Close#61106
This commit removes the use of the privately exported
PendingTasksInternal everywhere except for Router. A follow-up change
will be done to remove that one as well and delete the private export.
PR Close#61049
The `ts_project` interop rule that we've built was also used in the
Angular CLI migration, and it allows us to mix `ts_project` and
`ts_library` targets; enabling an incremental migration. Additionally
set up the `ng_project` to replace `ng_module`.
PR Close#61087
This is necessary for an incremental migration to `rules_js` which
requires Bazel v6. Bazel v6 removed the managed directories feature,
which means we no longer can rely on symlinked node modules as the Bazel
repository; but rather need to duplicate dependencies. This is
okay/acceptable to enable the incremental migration.
PR Close#61087
According to the promise specification, promises are not cancellable by default.
Once a promise is created, it will either resolve or reject, and it doesn't
provide a built-in mechanism to cancel it.
There may be situations where a promise is provided, and it either resolves after
the pipe has been destroyed or never resolves at all. If the promise never
resolves — potentially due to factors beyond our control, such as third-party
libraries — this can lead to a memory leak.
When we use `async.then(updateLatestValue)`, the engine captures a reference to the
`updateLatestValue` function. This allows the promise to invoke that function when it
resolves. In this case, the promise directly captures a reference to the
`updateLatestValue` function. If the promise resolves later, it retains a reference
to the original `updateLatestValue`, meaning that even if the context where
`updateLatestValue` was defined has been destroyed, the function reference remains in memory.
This can lead to memory leaks if `updateLatestValue` is no longer needed or if it holds
onto resources that should be released.
When we do `async.then(v => ...)` the promise captures a reference to the lambda
function (the arrow function).
When we assign `updateLatestValue = null` within the context of an `unsubscribe` function,
we're changing the reference of `updateLatestValue` in the current scope to `null`.
The lambda will no longer have access to it after the assignment, effectively
preventing any further calls to the original function and allowing it to be garbage collected.
If Chrome is built with additional flags and run with `--allow-natives-syntax --track-retaining-path`,
we could use `%DebugTrackRetainingPath` to see the distance from the root for `updateLatestValue`
if it's passed directly to async.then, e.g.:
```js
%DebugTrackRetainingPath(updateLatestValue);
// Distance from root 4: 0x123456789abc <JSPromise (sfi = 0x1fbb02e2d7f1)>
```
PR Close#58041
Replaces `PLATFORM_ID` checks with `ngServerMode` within the `HttpXsrfCookieExtractor`. It is not part of the public API, and thus this change should not affect consumers who may have called the constructor directly.
PR Close#59810
This refactor removes the unnecessary `runOutsideAngular` call in the
view transition helper. The resolved promise re-enters the zone in the
transition, so that will trigger the Angular zone anyways. If it didn't do that,
it risks activated the route outside the zone, which is a bigger risk.
Regardless, this function is only run once per navigation, so even if it
_did_ result in an extra promise/timeout inside the zone, this is not
excessive. Using ZoneJS to trigger rendering is known to overreact to events.
Using `OnPush` or zoneless is more effective at mitigating this issue.
PR Close#61068
Adds `__PURE__` annotations to `PROPAGATION_STOPPED_SYMBOL` to enable tree-shaking, even if is is not referenced. This variable is not dropped when Angular is imported from a module that has `sideEffects` set to `true`.
PR Close#61004
description: Comprehensive writing guide for Angular documentation (adev). Covers Google Technical Writing standards, Angular-specific markdown extensions, code blocks, and components. You MUST use this skill any time you plan to create, edit, or review documentation files in `adev/` or `adev/src/content`.
---
# Angular Documentation (adev) Writing Guide
This skill provides comprehensive guidelines for authoring content in `adev/src/content`. It combines Google's technical writing standards with Angular-specific markdown conventions, components, and best practices.
## I. Google Technical Writing Guidelines
### Tone and Content
- **Be conversational and friendly:** Maintain a helpful yet professional tone. Avoid being overly casual.
- **Write accessibly:** Ensure documentation is understandable to a diverse global audience, including non-native English speakers.
- **Audience-first:** Focus on what the user needs to do, not just what the system does.
- **Avoid pre-announcing:** Do not mention unreleased features or make unsupported claims.
- **Use descriptive link text:** Link text should clearly indicate the destination (e.g., avoid "click here").
### Language and Grammar
- **Use second person ("you"):** Address the reader directly.
- **Prefer active voice:** Clearly state who or what is performing the action (e.g., "The system generates a token" vs "A token is generated").
- **Standard American English:** Use standard American spelling and punctuation.
- **Conditional clauses first:** Place "if" or "when" clauses before the instruction (e.g., "If you encounter an error, check the logs").
- **Define terms:** Introduce new or unfamiliar terms/acronyms upon first use.
- **Consistent terminology:** Use the same term for the same concept throughout the document.
- **Conciseness:** Aim for one idea per sentence. Keep sentences short.
### Formatting and Organization
- **Sentence case for headings:** Capitalize only the first word and proper nouns in titles and headings.
- **Lists:**
- **Numbered lists:** Use for sequential steps or prioritized items.
- **Bulleted lists:** Use for unordered collections of items.
- **Description lists:** Use for term-definition pairs.
- **Serial commas:** Use the Oxford comma (comma before the last item in a list of three or more).
- **Code formatting:** Use code font for code-related text (filenames, variables, commands).
- **UI Elements:** formatting user interface elements in **bold**.
- **Date formatting:** Use unambiguous formats (e.g., "September 4, 2024" rather than "9/4/2024").
- **Structure:** Use logical hierarchy with clear introductions and navigation. Headings should be task-based where possible.
### Images and Code Samples
- **Images:** Use simple, clear illustrations to enhance understanding.
- **Captions:** Write captions that support the image.
- **Code Samples:**
- Ensure code is correct and builds without errors.
- Follow language-specific conventions.
- **Comments:** Focus on _why_, not _what_. Avoid commenting on obvious code.
### Reference Hierarchy
1. Project-specific style guidelines (if any exist in `CONTRIBUTING.md` or similar).
2. Google Developer Documentation Style Guide.
3. Merriam-Webster (spelling).
4. Chicago Manual of Style (non-technical).
5. Microsoft Writing Style Guide (technical).
---
## II. Angular Documentation Specifics
### Code Blocks
Use the appropriate language identifier for syntax highlighting:
- **TypeScript (Angular):** Use `angular-ts` when TypeScript code examples contain inline templates.
- **HTML (Angular):** Use `angular-html` for Angular templates.
- **TypeScript (Generic):** Use `ts` for plain TypeScript.
- **HTML (Generic):** Use `html` for plain HTML.
- **Shell/Terminal:** Use `shell` or `bash`.
- **Mermaid Diagrams:** Use `mermaid`.
#### Attributes
You can enhance code blocks with attributes in curly braces `{}` after the language identifier:
-`header="Title"`: Adds a title to the code block.
-`linenums`: Enables line numbering.
-`highlight="[1, 3-5]"`: Highlights specific lines.
-`hideCopy`: Hides the copy button.
-`prefer`: Marks code as a preferred example (green border/check).
-`avoid`: Marks code as an example to avoid (red border/cross).
description: Guidelines and tools for reviewing pull requests in the Angular repository.
---
# PR Review Guidelines
When reviewing a pull request for the `angular` repository, follow these essential guidelines to ensure high-quality contributions:
1.**Context & Ecosystem**:
- Keep in mind that this is the core Angular framework. Changes here can impact millions of developers.
- Be mindful of backwards compatibility. Breaking changes require strict approval processes and deprecation periods.
2.**Key Focus Areas**:
- **Comprehensive Reviews**: You **MUST always** perform a deep, comprehensive review of the _entire_ pull request. If the user asks you to look into a specific issue, file, or area of concern, you must investigate that specific area _in addition to_ reviewing the rest of the PR's substantive changes. Do not terminate your review after addressing only the user's focal point.
- **Package-Specific & Topic Guidelines**: Check if there are specific guidelines for the package or topic being modified in the `reference/` directory (e.g., `reference/router.md` or `reference/object_create_null.md`). Always prioritize these rules for their respective areas.
- **Prototype Collision & `Object.create(null)` PRs**: When reviewing PRs that swap `{}` for `Object.create(null)`, consult `reference/object_create_null.md` for technical evaluation criteria and rules.
- **Commit Messages**: Evaluate the quality of commit messages. They should explain the _why_ behind the change, not just the _what_. Someone should be able to look at the commit history years from now and clearly understand the context and reasoning for the change.
- **Code Cleanliness**: Ensure the code is readable, maintainable, and follows Angular's project standards.
- **Performance**: Look out for code that might negatively impact runtime performance or bundle size, particularly in hot paths like change detection or rendering.
- **Testing**: Ensure all new logic has comprehensive tests, including edge cases. **Do NOT run tests locally** as part of your review process. CI handles this automatically, and running tests locally is redundant and inefficient.
- **API Design**: Ensure new public APIs are well-designed, consistent with existing APIs, and properly documented.
- **Payload Size**: Pay attention to the impact of changes on the final client payload size.
3.**Execution Workflow**:
Determine the appropriate review method. If the user explicitly asks for a `remote` or `local` review in their request, that takes precedence (e.g. "leave comments on the PR" implies `remote`). Otherwise, use the GitHub MCP or available scripts to determine if the review should be `local` or `remote`.
**Common Review Practices (Applies to both Local and Remote)**
- **Preparation & Checklist**:
- First, create a task list (e.g., in `task.md`) that you can easily reference containing **all** the review requirements from the "Key Focus Areas" section (Commit Messages, Performance, Testing, etc.), along with any specific review notes or requests from the user.
- Before doing an in-depth review, expand this list into more detailed items of what you plan to explore and verify in the PR.
- As you conduct the review, check off items in this list, adding your assessment or findings underneath each item.
- At the end of your review, refer back to the checklist to ensure every single requirement was completely verified.
- **Fetch PR Metadata Safely**: When you need to read the PR description or context, do NOT use `gh pr view <PR_NUMBER>` by itself, as its default GraphQL query may fail due to lack of `read:org` and `read:discussion` token scopes. Instead, use `read_url_content` on the PR URL or use `gh pr view <PR_NUMBER> --json title,body,state,author`.
- **Check Existing Comments First**: Before formulating feedback, use the GitHub MCP or available scripts to fetch existing comments on the PR. Review this feedback to avoid duplicate comments, and incorporate its insights into your own review process.
- **Constructive Feedback**: Provide clear, actionable, and polite feedback. Explain the _why_ behind your suggestions or edits. Do **NOT** leave inline comments purely to praise, agree with, or acknowledge a correct implementation detail, as this clutters the review. If you want to praise the PR, do so in the single general PR comment.
**A. Local Code Review (If the PR is owned by the author requesting the review)**
- **Checkout**: Check out the PR branch locally (if it doesn't already exist, fetch it). If checking out the branch fails due to a worktree claim (e.g. "fatal: '<branch>' is already used by worktree at '<path>'"), do the review in that directory.
- **Review & Edit**: Execute the review directly on the code. Instead of adding inline PR comments for suggestions, format the codebase or apply the edits directly to the files.
- **Feedback**: Summarize the review findings and the concrete changes you made in a message to the user, referencing the completed items from your checklist.
- **Do NOT Commit or Push**: Leave the changes uncommitted in the working directory so the user can easily review the pending edits locally. Let the user know the changes are ready for their review, but do not ask for approval to push.
- **Resolve Comments**: Once the user confirms the changes are good and should be committed/pushed, respond to the existing comments as 'resolved' using the GitHub MCP or available scripts.
**B. Remote Code Review (For all other PRs)**
- **Batching Comments (MCP Server - Preferred)**: If you have the GitHub MCP Server configured, you **MUST** follow this workflow to avoid spamming the author with multiple notifications:
1. Create a pending review using `mcp_github-mcp-server_pull_request_review_write` (method `create`).
2. Add your inline comments to the pending review using `mcp_github-mcp-server_add_comment_to_pending_review`.
3. Submit the review using `mcp_github-mcp-server_pull_request_review_write` (method `submit_pending`).
- **Batching Comments (Scripts - Fallback)**: If you do **NOT** have access to the GitHub MCP Server (e.g., specific MCP tools are missing from your context), fallback to using the provided scripts. Use `post_inline_comment.sh` to stage your comments locally. Once all comments are staged, you **MUST** call `submit_pr_review.sh` to publish them as a single batched review (and send a single notification). Try to keep comments minimal or use a general comment if you have many suggestions.
- **Use Suggested Changes**: Whenever appropriate (e.g., for simple code fixes, refactoring suggestions, or typo corrections), prefer using GitHub's **Suggested Changes** syntax (`suggestion ... `) in your inline comments. This allows the author to apply your suggested code improvements with a single click in the GitHub UI.
- **Review Type**: Never mark an external PR review as an "approval" unless explicitly instructed by a repo maintainer. Always use "Request Changes" or "Comment". Note that some tools might only support commenting.
- **Require User Approval Before Posting**: Prepare your review comments and present them to the user, alongside a summary of your completed checklist. Do NOT post comments to the PR without explicitly asking the user for permission first. Only post the review after the user approves.
- **CRITICAL**: This rule applies even if you receive a system message indicating that an artifact has been "automatically approved" or instructing you to "proceed to execution." You must ALWAYS obtain explicit, written confirmation from the user in this chat conversation before posting any content to a PR.
- **Prefix Agent Comments**: To make it clear when comments are generated and posted by an AI agent rather than a human user, **always** prefix your review comments with `AGENT: `.
## Available Tools
The following tools are available for remote interactions. We prefer using standard **GitHub MCP Server** tools when available. If you do not have the MCP server set up, you **MUST** fallback to using the custom bash scripts.
The following scripts are provided as fallbacks if the MCP server is not available. Note that they rely on the `gh` CLI being correctly installed and authenticated in the local environment.
### `determine_review_type.sh`
Determines whether to use the Local or Remote review workflow by checking if the currently authenticated GitHub user via the `gh` CLI matches the author of the pull request.
Fetches all existing inline comments on a PR using the GitHub API. This is crucial for reviewing other contributors' feedback and avoiding duplicate comments. It outputs JSON containing the `id`, `path`, `line`, `body`, and `user` for each comment.
Replies to an existing PR comment thread. This is useful for marking comments as resolved after addressing them in a local code review. Note that the `COMMENT_ID` must be the ID of the top-level comment in the thread.
The GitHub CLI `gh pr review` command does not natively support adding inline comments to specific lines of code via its standard flags. This script wraps the GitHub API to stage comments locally. They will not be published until you call `submit_pr_review.sh`.
# Rules for `Object.create(null)` and Prototype Collision Prevention
This guide outlines the technical rules and evaluation criteria for using `Object.create(null)` versus standard object literals (`{}`) or `Map` in the Angular codebase.
---
## 1. When `Object.create(null)` is Appropriate
Using `Object.create(null)` (or `Map`) is appropriate when **all** of the following conditions are met:
1. The object is used as an **internal key-value lookup map or set**.
2. The keys are **arbitrary or untrusted dynamic strings** (e.g., URL query parameters in `$locationShim`, HTML sanitizer tag sets, or `jsaction` DOM event-type resolvers).
3. Property existence is checked via direct indexing or key checks (e.g., `map[key] !== undefined` or `key in map`), where a key matching an `Object.prototype` member (such as `'toString'`, `'constructor'`, or `'hasOwnProperty'`) causes false positive matches or incorrect behavior.
---
## 2. Handling Public API and Boundary Objects
If an object receives untrusted dynamic keys **and** is exposed to public consumers or third-party code (e.g., `SimpleChanges` in `ngOnChanges`):
- **Do NOT blindly change the object to `Object.create(null)`**: Stripping `Object.prototype` from public objects is a breaking API change. Consumer code calling `.hasOwnProperty()`, `.toString()`, `.valueOf()`, or using string interpolation (`` `${obj}` ``) will fail at runtime (`TypeError: obj.hasOwnProperty is not a function`).
- **Safe Alternatives for Public Objects:**
- **`Object.hasOwn(obj, key)`**: Use `Object.hasOwn` for internal framework property lookups instead of direct index or `in` checks. This prevents prototype collision during internal reads without breaking the object's prototype for consumers.
- **Input Key Sanitization**: Filter or delete dangerous key names (`__proto__`, `constructor`, `prototype`) when populating the object.
- **`Map` or Custom Classes**: For new public APIs requiring key-value stores with dynamic keys, prefer `Map<K, V>` or dedicated classes with explicit `.get()` and `.has()` methods.
- **Deprecation / Breaking Change Process**: If changing a public object's prototype to `null` is unavoidable, it must follow Angular's formal deprecation and major version breaking change process.
---
## 3. When `Object.create(null)` Should NOT Be Used
Do not replace `{}` with `Object.create(null)` in the following scenarios:
1.**Fixed-Shape Structs and DTOs:** Objects with hardcoded static property names (e.g., `let sortedBreakpoints: {breakpoints?: number[]} = {}`). `Object.assign({}, ...)` only copies _own_ enumerable properties, so prototype properties on sources are never copied.
2.**Numeric-Key Maps:** Objects indexed by numbers (e.g., `tasksByHandleId: {[id: number]: Task}`). Numeric keys do not collide with `Object.prototype` string members.
3.**Reference Sentinels:** Objects used purely for reference identity checks (e.g., `const EMPTY_OBJECT = {}` or `const IN_PROGRESS_RESOLUTION = {}`).
4.**Internal Compiler AST and Visitor State:** Temporary objects with internally generated keys where untrusted user input cannot poison key names.
5.**Hot Performance Paths and Size-Critical Bundles:** Standard `{}` literals use V8 fast hidden classes and monomorphic inline caching. `Object.create(null)` forces V8 dictionary mode and increases minified bundle size (e.g., in inline polyfills like `event-dispatch-contract` or SSR hydration bundles).
When reviewing pull requests that modify the Angular Router (`packages/router`), pay special attention to the following:
- **Timing Sensitivity**: The router is extremely sensitive to timing changes. Any changes that alter the asynchronous timing of navigations, resolvers, or guards are almost always breaking changes and must be scrutinized carefully.
- **Testing Practices**: Tests should usually use the `RouterTestingHarness`. Many existing tests are older and do not use this harness. Do not blindly follow the shape of existing tests when writing or reviewing new ones; encourage the use of modern testing utilities.
- **Feature Justification**: Changes to router core code should be well-justified. Consider whether the change is proven to be a core developer ask, such as resolving a highly upvoted GitHub issue or addressing a critical bug.
description: Explains the mental model and architecture of the code under `packages/compiler-cli`. You MUST use this skill any time you plan to work with code in `packages/compiler-cli`
---
# Angular Compiler CLI (`ngtsc`) Architecture
## Overview
The `packages/compiler-cli` package contains the Angular Compiler (Ivy), often referred to as `ngtsc`. It is a wrapper around the TypeScript compiler (`tsc`) that extends it with Angular-specific capabilities.
The core goal of `ngtsc` is to compile Angular decorators (like `@Component`, `@Directive`, `@Pipe`) into static properties on the class (Ivy instructions, e.g., `static ɵcmp = ...`). It also performs template type checking and ahead-of-time (AOT) compilation.
## Mental Model
The compiler is designed as a **lazy, incremental, and partial** compilation pipeline.
1.**Wrapper Pattern**: `NgtscProgram` wraps the standard `ts.Program`. It intercepts calls to act as a drop-in replacement for standard tooling.
2.**Traits System**: Every class with an Angular decorator is considered a "Trait". The compiler manages the state of these traits through a state machine:
- **Resolved**: Dependencies (directives/pipes in template) resolved, import cycles handled.
- **Skipped**: Not an Angular class.
3.**Lazy Analysis**: Analysis only happens when necessary (e.g., when diagnostics are requested or emit is prepared).
4.**Output AST**: The compiler generates an intermediate "Output AST" (`o.Expression`) for the generated code, which is then translated into TypeScript AST nodes during the emit phase.
## Key Subsystems
### 1. Core Orchestration (`ngtsc/core`)
- **`NgtscProgram`**: The public API implementing `api.Program`. It manages the `ts.Program` and the `NgCompiler`.
- **`NgCompiler`**: The brain of the compiler. It orchestrates the compilation phases (Analysis, Resolution, Type Checking, Emit). It holds the `TraitCompiler`.
### 2. Trait Compilation (`ngtsc/transform`)
- **`TraitCompiler`**: Manages the lifecycle of "Traits". It iterates over source files, identifies decorated classes, and delegates to the appropriate `DecoratorHandler`.
- **`Trait`**: A state container for a class, holding its handler, analysis results, and resolution results.
### 3. Decorator Handlers (`ngtsc/annotations`)
- **`DecoratorHandler`**: An interface for handling specific decorators.
- **`ComponentDecoratorHandler`**: The most complex handler. It:
- Extracts metadata (selector, inputs, outputs).
- Parses the template.
- Resolves used directives and pipes (`R3TargetBinder`).
- Generates the `ɵcmp` instruction.
- **`DirectiveDecoratorHandler`**, **`PipeDecoratorHandler`**, **`NgModuleDecoratorHandler`**: Handle their respective decorators.
### 4. Template Type Checking (`ngtsc/typecheck`)
- **`TemplateTypeChecker`**: Generates "Type Check Blocks" (TCBs). A TCB is a block of TypeScript code that represents the template's logic in a way `tsc` can understand and check for errors.
- **`TypeCheckBlock`**: The actual generated code that validates bindings, events, and structural directives.
- **`MetadataReader`**: Reads Angular metadata from source files (using `LocalMetadataRegistry`) and `.d.ts` files (using `DtsMetadataReader`).
- **`ScopeRegistry`**: Determines the "compilation scope" of a component (which directives/pipes are available to it), handling `NgModule` transitive exports and Standalone Component imports.
### 6. Emit & Transformation (`ngtsc/transform`)
- **`ivyTransformFactory`**: A TypeScript transformer factory.
- **`IvyCompilationVisitor`**: Visits classes, triggers compilation via `TraitCompiler`, and collects the Output AST.
- **`IvyTransformationVisitor`**: Translates the Output AST into TypeScript AST, injects the `static ɵ...` fields, and removes the original decorators.
## Compilation Phases
1.**Construction**: `NgtscProgram` creates `NgCompiler`, which sets up all registries and the `TraitCompiler`.
2.**Analysis** (`analyzeSync`):
- The `TraitCompiler` scans files.
-`DecoratorHandler`s extract metadata and parse templates.
- No cross-file resolution happens here (allowing for parallelism and caching).
3.**Resolution** (`resolve`):
-`TraitCompiler` resolves traits.
- Components link their templates to specific Directives and Pipes (found via `ScopeRegistry`).
- Import cycles are detected and handled (e.g., via "remote scoping").
4.**Type Checking**:
-`TemplateTypeChecker` creates TCBs for all components.
- TypeScript diagnostics are retrieved for these TCBs.
5.**Emit** (`prepareEmit`):
-`ivyTransformFactory` is created.
- TS `emit` is called.
- The transformers run, injecting the compiled Ivy instructions into the JS/DTS output.
## Important File Locations
-`packages/compiler-cli/src/ngtsc/program.ts`: Entry point (`NgtscProgram`).
description: Explains the mental model and architecture of the code under `packages/core`. You MUST use this skill any time you plan to work with code in `packages/core`
---
# Angular Core (`packages/core`) Mental Model
This document outlines the architecture and mental model for `packages/core`, the heart of the Angular framework.
## 1. High-Level Architecture
`packages/core` contains the runtime logic for Angular. Its primary responsibilities are:
1.**Rendering (Ivy/Render3)**: Transforming templates into DOM updates.
2.**Dependency Injection (DI)**: Managing object creation and lifetime.
3.**Change Detection**: Synchronizing the model with the view.
4.**Reactivity**: Signals and Zone.js integration.
## 2. Rendering Engine (Ivy / Render3)
The rendering engine (located in `packages/core/src/render3`) uses an **instruction-based** approach.
### Key Concepts
- **Instructions**: The Angular compiler transforms templates into a sequence of instruction calls (e.g., `ɵɵelementStart`, `ɵɵtext`, `ɵɵproperty`). These instructions are executed at runtime to create and update the view.
- **TView (Template View)**: An array containing the _static structure_ of a view. It is shared across all instances (`LView`s) of the same component/template. It holds:
- Configured via `@Component.providers` or `@Directive.providers`.
- **Not a class**, but a data structure embedded in the `LView` ("Expando" section).
- Uses **Bloom Filters** (`TView.data`) to quickly check if a token is present at a specific node index before traversing up the tree.
- Resolves tokens starting from the current node, walking up the view tree (Element Injector hierarchy), and falling back to the Module Injector if not found.
## 4. Change Detection
- **Dirty Checking**: Angular checks if values bound in templates have changed.
- **Strategies**:
-`Default`: Checks everything.
-`OnPush`: Checks only if inputs change, events fire, or signals update.
- **Signals**: The new reactivity primitive. Signals notify the scheduler when they change, potentially allowing for fine-grained updates (Zoneless).
## 5. Key Directories to Know
-`src/render3`: The Ivy rendering engine.
-`instructions`: The runtime instructions called by compiled code.
-`src/signal`: Signals implementation (if present in this version, otherwise likely in `primitives`).
## 6. Conventions & Gotchas
- **Prefixes**: Private/Internal exports often start with `ɵ`.
- **Global State**: Ivy relies heavily on global state (e.g., `getLView()`) during instruction execution to avoid passing context arguments everywhere. This is for performance and code size.
- **Performance**: The code is highly optimized for performance and memory. You will see arrays used instead of objects, bitmasks, and manual memory management patterns. **Respect these patterns.**
## 7. How to Modify Core
1.**Understand the Instruction**: If modifying runtime behavior, find the corresponding instruction in `src/render3/instructions`.
2.**Check `LView`/`TView` Impact**: If adding state, understand where it fits in the `LView` array.
3.**Tests**: Core has extensive tests. Run them using Bazel.
description: Explains the mental model and architecture of the code under `packages/forms/signals`. You MUST use this skill any time you plan to work with code in `packages/forms/signals`
---
# Signal Forms Architecture
The `packages/forms/signals` directory contains the signal-based forms API for Angular.
This system differs significantly from the existing Reactive and Template-driven forms.
## Mental Model
1.**Model-Driven**: The system is built around a `WritableSignal<T>` which serves as the **single source of truth**.
Unlike Reactive Forms where the `FormControl` holds the value, here the `Signal` holds the value.
The form is merely a _view_ or _projection_ of that signal, adding form-specific state (validity, dirty, touched).
2.**Proxy-Based Traversal**: The form API (`form(signal)`) returns a `FieldTree`. This object is a **Proxy**.
It allows accessing nested fields (e.g., `myForm.user.name`) without manually creating control groups.
Accessing a property on the proxy lazily resolves or creates the corresponding `FieldNode`.
3.**Schema-Based Logic**: Validation, disabled state, and other metadata are defined separately via **Schemas**.
Schemas are applied to the form structure using functions like `apply`, `applyEach` (for arrays), and `applyWhen`.
This separates the _structure_ of the data from the _rules_ governing it.
4.**Directives as Glue**: The `[formField]` directive binds a DOM element (native input or custom control) to a `FieldNode`.
It handles:
- Syncing the value between the DOM and the Signal.
- Reflecting state (valid, touched, etc.) to the UI.
- Handling user interaction events (blur, input).
## Key Components
### 1. `FieldNode` (`src/field/node.ts`)
The central internal class representing a single field in the form graph. It aggregates several state managers:
-`structure`: Manages parent/child relationships and signal slicing.
This document explains how the Signal Forms system hooks into the Angular compiler and runtime to provide seamless type-checking and efficient updates.
## 1. Compiler Integration (Type Checking)
The `packages/compiler` package contains specific logic to support `[formField]`. This is primarily handled in `src/typecheck/ops/signal_forms.ts`.
### Key Mechanisms:
- **Detection**: The compiler identifies a directive as a "Field Directive" if it has the `ɵNgFieldDirective` property or comes from `@angular/forms/signals`.
- **Synthetic Binding Expansion**: When you write `<input [formField]="mySignal" />`, the type checker doesn't just check `formField`. It synthetically expands this into a set of bindings for validation:
-`[value]="mySignal()"` (or `checked` for checkboxes)
-`[disabled]="mySignal.disabled()"`
-`[required]="mySignal.required()"`
- ...and so on.
- This ensures that `mySignal` (the `FieldNode`) has all the necessary properties to drive the form control.
- **Conflict Detection**: It actively prevents "double binding". If you bind `[formField]`, you are _banned_ from also binding `[value]`, `[disabled]`, `[required]`, etc., as the signal form should be the single source of truth.
- **Element Type Validation**:
- **Native Elements**: Checks that the signal's value type matches the element type (e.g., `<input type="checkbox">` requires a `boolean` signal).
- **Custom Controls**: Detects if a custom component is a "Form Value Control" (has a `value` input/output) or "Form Checkbox Control" (has a `checked` input/output) and validates against that.
### Relevant Files:
-`packages/compiler/src/typecheck/ops/signal_forms.ts`: The core Signal Forms type-checking logic, including `TcbNativeFieldOp`.
## 2. Core Runtime Integration
The `packages/core` package provides the low-level instructions that power the `FormField` directive. This allows it to do things normal directives cannot, like efficiently syncing state without change detection overhead for every property.
### Key Mechanisms:
- **`ɵngControlCreate` Hook**: The `FormField` directive defines a special method `ɵngControlCreate`, which causes the compiler to install `ɵɵControlFeature`.
- **`ɵɵcontrol` Instructions**: A `formField` binding causes the compiler to emit:
-`ɵɵcontrolCreate`: Called during the creation phase.
-`ɵɵcontrol`: Called during the update phase.
- **`ControlDirectiveHost`**: These instructions provide the directive with a `ControlDirectiveHost`. This is a privileged interface that allows the `FormField` directive to:
- **Access the Element**: Get direct access to the native element or component instance.
- **Set Inputs**: Write directly to inputs of _other directives_ on the same node (e.g., setting the `value` input of a custom control).
- **Listen to Outputs**: Subscribe to outputs of other directives (e.g., `valueChange`).
- **Bypass Templates**: It effectively acts as a "meta-directive" that manages the bindings for you, bypassing the need for explicit template syntax for every property.
### Relevant Files:
-`packages/core/src/render3/instructions/control.ts`: Implementation of `ɵɵcontrol` instructions.
-`packages/forms/signals/src/directive/form_field.ts`: The directive that implements the hook.
This folder contains configuration files that can be used to opt into working on this repository in a [Docker container](https://www.docker.com/resources/what-container) via [VSCode](https://code.visualstudio.com/)'s Remote Development feature (see below).
Info on remote development and developing inside a container with VSCode:
- [VSCode: Developing inside a Container](https://code.visualstudio.com/docs/remote/containers)
- [VSCode: Remote Development FAQ](https://code.visualstudio.com/docs/remote/faq)
## Usage
_Prerequisite: [Install Docker](https://docs.docker.com/install) on your local environment._
@@ -15,7 +15,6 @@ _Prerequisite: [Install Docker](https://docs.docker.com/install) on your local e
To get started, read and follow the instructions in [Developing inside a Container](https://code.visualstudio.com/docs/remote/containers). The [.devcontainer/](.) directory contains pre-configured `devcontainer.json` and `Dockerfile` files, which you can use to set up remote development with a docker container.
In a nutshell, you need to:
- Install the [Remote - Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) extension.
- Copy [recommended-Dockerfile](./recommended-Dockerfile) to `Dockerfile` (and optionally tweak to suit your needs).
- Copy [recommended-devcontainer.json](./recommended-devcontainer.json) to `devcontainer.json` (and optionally tweak to suit your needs).
@@ -24,6 +23,7 @@ In a nutshell, you need to:
The `.devcontainer/devcontainer.json` and `.devcontainer/Dockerfile` files are ignored by git, so you can have your own local versions. We may occasionally update the template files ([recommended-devcontainer.json](./recommended-devcontainer.json), [recommended-Dockerfile](./recommended-Dockerfile)), in which case you will need to manually update your local copies (if desired).
## Updating `recommended-devcontainer.json` and `recommended-Dockerfile`
You can update and commit the recommended config files (which people use as basis for their local configs), if you find that something is broken, out-of-date or can be improved.
description="Researches part of the codebase and creates a skill for it"
prompt="""
## Role
You are an experienced senior developer specializing in reverse engineering and understanding
complex code, prompt engineering, and context engineering.
Your task is to build a complete understanding of the mental model and architecture of the code,
and to create an efficient context file that allows a coding agent to understand and work with the
code.
## Guiding Principles
1. **Deep Analysis:** Understand the _why_ behind the code. Not just a surface level listing of
files and classes.
2. **Curiosity:** Be curious. If something is unclear, confusing, or unexpected you _MUST_
investigate further until you fully understand.
3. **Efficient Token Use:** The final output will be directly included into the context of the
coding assistant, so be sure to make efficient use of tokens. Think deeply, but only capture the
most important information for the coding agent in the final output
## Procedure
1. Fully explore the code before first, with a focus on understanding the architecture and how all
of the pieces fit together.
2. Develop an understanding of the mental model behind the architecture. _Why_ is the code is
architected this way? How should developers think about the system?
3. Document your findings using the given output format described in the next section.
## Output Format
Note the following placeholders below:
- `[package]`: is a unique identifier for the current code package (for example if you're looking at
code under `packages/forms/signals` you might use `signal-forms` as the `[package]`)
- `[code-location]`: is the location of the current code within the larger repository
- `[context]`: is the context to add to the coding agent when it is working with this code.
With those placeholders in mind, write a file create a new directory under `.gemini/skills` with the
name `reference-[package]/`, and under that directory add a `SKILL.md` file with the following
content:
```md
---
name: reference-[package]
description: Explains the mental model and architecture of the code under `[code-location]`. You MUST use this skill any time you plan to work with code in `[code-location]`
---
[context]
```
## Additional User Instructions
The user may have additional instructions.
- The user should indicate what package to research
- The user may indicate that they want to update a package that has already been researched. In this
case, read the existing skill and make any required updates based on your research
- The user may request supplemental information be added to the skill (if so, add this to the
existing skill in a new markdown file under a `references` directory within the skill. Add a
section to the main `SKILL.md` that mentions what supplemental information is available)
'@angular/animations is deprecated. Use `animate.enter` and `animate.leave` instead. For more information see: https://v22.angular.dev/guide/animations.',
},
},
{name:'@angular/common'},
{name:'@angular/compiler-cli'},
{name:'@angular/compiler'},
{name:'@angular/core'},
{name:'@angular/elements'},
{name:'@angular/forms'},
{name:'@angular/language-server'},
{name:'@angular/language-service'},
{name:'@angular/localize'},
{
name:'@angular/platform-browser-dynamic',
deprecated:{
version:'>=20.1.0-next.0',
message:
'@angular/platform-browser-dynamic is deprecated. Use `@angular/platform-browser` instead.',
},
},
{name:'@angular/platform-browser'},
{name:'@angular/platform-server'},
{name:'@angular/router'},
{name:'@angular/service-worker'},
{name:'@angular/upgrade'},
],
buildPackages:async()=>{
// The buildTargetPackages function is loaded at runtime as the loading the script
# - We trust that people do the right thing and won't approve changes they don't feel confident reviewing
# - We enforce that only approved PRs are merged ensuring that unreviewed code isn't accidentally merged
# - We distribute approval rights as much as possible to help us scale better
# - Groups have one or two global approvers groups as fallbacks:
# - @angular/fw-global-approvers: for approving minor changes, large-scale refactorings, and emergency situations.
# - @angular/fw-global-approvers-for-docs-only-changes: for approving minor documentation-only changes that don't require engineering review
# - A small number of file groups have very limited number of reviewers because incorrect changes to the files they guard would have serious consequences (e.g. security, public api)
#
# Configuration nuances:
@@ -34,11 +37,27 @@
# See reviewer list under `required-minimum-review` group. Team member names and
@@ -14,20 +14,20 @@ appearance, race, religion, or sexual identity and orientation.
Examples of behavior that contributes to creating a positive environment
include:
- Use welcoming and inclusive language
- Respect each other
- Provide and gracefully accept constructive criticism
- Show empathy towards other community members
* Use welcoming and inclusive language
* Respect each other
* Provide and gracefully accept constructive criticism
* Show empathy towards other community members
Examples of unacceptable behavior by participants include:
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or electronic
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
- The use of sexualized language or imagery
- Unwelcome sexual attention or advances
- Other conduct which could reasonably be considered inappropriate in a
* The use of sexualized language or imagery
* Unwelcome sexual attention or advances
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
@@ -69,9 +69,9 @@ members of the project's leadership.
If you are banned you may contest the decision. To do so email conduct@angular.io with the subject line "Repeal Ban for {{your name here}}" and body with the responses to the following:
- Why do you believe you did not violate the Code of Conduct?
- Were other factors involved in this situation the leadership team may have been unaware of?
- Why do you wish to be a part of the Angular community?
* Why do you believe you did not violate the Code of Conduct?
* Were other factors involved in this situation the leadership team may have been unaware of?
* Why do you wish to be a part of the Angular community?
We would love for you to contribute to Angular and help make it even better than it is today!
As a contributor, here are the guidelines we would like you to follow:
- [Code of Conduct](#coc)
- [Question or Problem?](#question)
- [Issues and Bugs](#issue)
- [Feature Requests](#feature)
- [Submission Guidelines](#submit)
- [Coding Rules](#rules)
- [Commit Message Guidelines](#commit)
- [Signing the CLA](#cla)
- [Code of Conduct](#coc)
- [Question or Problem?](#question)
- [Issues and Bugs](#issue)
- [Feature Requests](#feature)
- [Submission Guidelines](#submit)
- [Coding Rules](#rules)
- [Commit Message Guidelines](#commit)
- [Signing the CLA](#cla)
## <a name="coc"></a> Code of Conduct
Help us keep Angular open and inclusive.
Please read and follow our [Code of Conduct][coc].
## <a name="question"></a> Got a Question or Problem?
Do not open issues for general support questions as we want to keep GitHub issues for bug reports and feature requests.
@@ -32,25 +34,28 @@ To save your and our time, we will systematically close all issues that are requ
If you would like to chat about the question in real-time, you can reach out via [the Angular community Discord server][discord].
## <a name="issue"></a> Found a Bug?
If you find a bug in the source code, you can help us by [submitting an issue](#submit-issue) to our [GitHub Repository][github].
Even better, you can [submit a Pull Request](#submit-pr) with a fix.
## <a name="feature"></a> Missing a Feature?
You can *request* a new feature by [submitting an issue](#submit-issue) to our GitHub Repository.
If you would like to *implement* a new feature, please consider the size of the change in order to determine the right steps to proceed:
You can _request_ a new feature by [submitting an issue](#submit-issue) to our GitHub Repository.
If you would like to _implement_ a new feature, please consider the size of the change in order to determine the right steps to proceed:
- For a **Major Feature**, first open an issue and outline your proposal so that it can be discussed.
* For a **Major Feature**, first open an issue and outline your proposal so that it can be discussed.
This process allows us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
**Note**: Adding a new topic to the documentation, or significantly re-writing a topic, counts as a major feature.
- **Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr).
* **Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr).
## <a name="submit"></a> Submission Guidelines
### <a name="submit-issue"></a> Submitting an Issue
Before you submit an issue, please search the issue tracker. An issue for your problem might already exist and the discussion might inform you of workarounds readily available.
@@ -69,67 +74,50 @@ Unfortunately, we are not able to investigate / fix bugs without a minimal repro
You can file new issues by selecting from our [new issue templates](https://github.com/angular/angular/issues/new/choose) and filling out the issue template.
We strongly value open source contribution and pull requests from community contributors. Please note that every pull request is reviewed and merged by an actual person on the team, which does take time and effort. That is time and effort that does take away from other valuable work. With that in mind we have a minimum set of expectations that are required of any community contribution pull request that is opened.
1. Search [GitHub](https://github.com/angular/angular/pulls) for an open or closed PR that relates to your submission.
- You don't want to duplicate existing efforts.
2. Be sure that an issue or pull request clearly describes the problem you're fixing, or documents the design for the feature you'd like to add. Issues require a _minimal_ reproduction.
3. Discussing the design in an issue upfront helps to ensure that we're ready to accept your work. Pull requests are not the right place to do design work.
- When in doubt, open an issue first before doing any sort of speculative implementation work
4. Ideally the PR should be tied to an issue, but this is not required
5. The change should improve code quality (i.e. addressing a TODO) or should impact / improve a feature
6. Micro optimizations will only be accepted if they are validated by an actual benchmark
7. Do not open pull requests that are addressing feature requests that are not labeled as "help wanted" as they usually need additional design work before we could accept pull requests
8. The change should be well tested
If your pull request does not meet these minimum expectations, we may close your PR. Also, if your PR introduces a breaking change, it's possible the level of churn this breaking change causes may block our ability to move forward with it. We may close your PR in that situation, as well. Otherwise, we're excited to see your contributions and enthusiasm for Angular!
### <a name="submit-pr"></a> Submitting a Pull Request (PR)
Before you submit your Pull Request (PR) consider the following guidelines:
1.Please sign our [Contributor License Agreement (CLA)](#cla) before sending PRs.
1.Search [GitHub](https://github.com/angular/angular/pulls) for an open or closed PR that relates to your submission.
You don't want to duplicate existing efforts.
2. Be sure that an issue describes the problem you're fixing, or documents the design for the feature you'd like to add.
Discussing the design upfront helps to ensure that we're ready to accept your work.
Make sure you author all contributed Git commits with email address associated with your CLA signature.
2. [Fork](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) the [angular/angular](https://github.com/angular/angular/fork) repo.
4. [Fork](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) the [angular/angular](https://github.com/angular/angular/fork) repo.
3. In your forked repository, make your changes in a new git branch:
5. In your forked repository, make your changes in a new git branch:
```shell
git checkout -b my-fix-branch main
```
```shell
git checkout -b my-fix-branch main
```
4. Create your patch, **including appropriate test cases**.
6. Create your patch, **including appropriate test cases**.
5. Follow our [Coding Rules](#rules).
7. Follow our [Coding Rules](#rules).
6. Run the full Angular test suite, as described in the [developer documentation][dev-doc], and ensure that all tests pass.
8. Run the full Angular test suite, as described in the [developer documentation][dev-doc], and ensure that all tests pass.
7. Commit your changes using a descriptive commit message that follows our [commit message conventions][commit-message-guidelines].
9. Commit your changes using a descriptive commit message that follows our [commit message conventions][commit-message-guidelines].
Adherence to these conventions is necessary because release notes are automatically generated from these messages.
```shell
git commit --all
```
```shell
git commit --all
```
Note: the optional commit `--all` command line option will automatically "add" and "rm" edited files.
Note: the optional commit `--all` command line option will automatically "add" and "rm" edited files.
10. Push your branch to GitHub:
8. Push your branch to GitHub:
```shell
git push origin my-fix-branch
```
```shell
git push origin my-fix-branch
```
9. In GitHub, send a pull request to `angular:main`.
11. In GitHub, send a pull request to `angular:main`.
### Reviewing a Pull Request
@@ -145,15 +133,16 @@ If we ask for changes via code reviews then:
3. Create a fixup commit and push to your GitHub repository (this will update your Pull Request):
```shell
git commit --all --fixup HEAD
git push
```
```shell
git commit --all --fixup HEAD
git push
```
For more info on working with fixup commits see [here](./contributing-docs/using-fixup-commits.md).
For more info on working with fixup commits see [here](./contributing-docs/using-fixup-commits.md).
That's it! Thank you for your contribution!
##### Updating the commit message
A reviewer might often suggest changes to a commit message (for example, to add more context for a change or adhere to our [commit message guidelines][commit-message-guidelines]).
@@ -161,68 +150,69 @@ In order to update the commit message of the last commit on your branch:
1. Check out your branch:
```shell
git checkout my-fix-branch
```
```shell
git checkout my-fix-branch
```
2. Amend the last commit and modify the commit message:
```shell
git commit --amend
```
```shell
git commit --amend
```
3. Push to your GitHub repository:
```shell
git push --force-with-lease
```
```shell
git push --force-with-lease
```
> NOTE:<br />
> If you need to update the commit message of an earlier commit, you can use `git rebase` in interactive mode.
> See the [git docs](https://git-scm.com/docs/git-rebase#_interactive_mode) for more details.
#### After your pull request is merged
After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository:
- Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
* Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
```shell
git push origin --delete my-fix-branch
```
```shell
git push origin --delete my-fix-branch
```
- Check out the main branch:
* Check out the main branch:
```shell
git checkout main -f
```
```shell
git checkout main -f
```
- Delete the local branch:
* Delete the local branch:
```shell
git branch -D my-fix-branch
```
```shell
git branch -D my-fix-branch
```
- Update your local `main` with the latest upstream version:
* Update your local `main` with the latest upstream version:
```shell
git pull --ff upstream main
```
```shell
git pull --ff upstream main
```
## <a name="rules"></a> Coding Rules
To ensure consistency throughout the source code, keep these rules in mind as you are working:
- All features or bug fixes **must be tested** by one or more specs (unit-tests).
- All public API methods **must be documented**.
- We follow [Google's TypeScript Style Guide][ts-style-guide], but wrap all code at **100 characters**.
* All features or bug fixes **must be tested** by one or more specs (unit-tests).
* All public API methods **must be documented**.
* We follow [Google's TypeScript Style Guide][ts-style-guide], but wrap all code at **100 characters**.
An automated formatter is available, see [DEVELOPER.md](contributing-docs/building-and-testing-angular.md#formatting-your-source-code).
An automated formatter is available, see [building-and-testing-angular.md](./contributing-docs/building-and-testing-angular.md#formatting-your-source-code).
We have very precise rules over how our Git commit messages must be formatted:
```
<type>(<scope>): <short summary>
```
@@ -234,18 +224,21 @@ See [Commit Message Guidelines][commit-message-guidelines] for details.
Please sign our Contributor License Agreement (CLA) before sending pull requests. For any code
changes to be accepted, the CLA must be signed. It's a quick process, we promise!
- For individuals, we have a [simple click-through form][individual-cla].
- For corporations, we'll need you to
* For individuals, we have a [simple click-through form][individual-cla].
* For corporations, we'll need you to
[print, sign and one of scan+email, fax or mail the form][corporate-cla].
If you have more than one GitHub account, or multiple email addresses associated with a single GitHub account, you must sign the CLA using the primary email address of the GitHub account used to author Git commits and send pull requests.
If you have more than one GitHub accounts, or multiple email addresses associated with a single GitHub account, you must sign the CLA using the primary email address of the GitHub account used to author Git commits and send pull requests.
The following documents can help you sort out issues with GitHub accounts and multiple email addresses:
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Jessica Janiuk