Removed redundant "src/app/" prefix from file headers (e.g.,
"src/app/open-close.component.ts" → "open-close.component.ts")
to make code examples cleaner and more focused.
(cherry picked from commit b3adb6001c)
This commit updates the elements and tailwind guides to use the standardized `docs-code-multifile` format for package manager commands. This change introduces `yarn`, `pnpm`, and `bun` alternatives to the existing `npm` commands, providing a consistent experience for users across different package managers.
(cherry picked from commit 6208016026)
If we're calling `min` on a path that's guaranteed to be `number` we
don't want to make the users validator function handle the `null` or
`string` cases.
This uncovered an issue in the `SchemaTreePath` type which needed to be
fixed by preventing the model type from being distributed over.
PR Close#65212
Relaxes the constraints on which paths can be used with the `min` &
`max` validation rules, since people may want to validate a
potentially-null number, or a numeric value represented as a string
PR Close#65212
The `type_check_block.ts` file was getting quite large and difficult to navigate. These changes split up the different pieces of functionality into separate files.
(cherry picked from commit 81bd455de8)
Test that a component with a bound `[field]` input is not treated as a
control, and that `fieldBinding` does not include the corresponding
`Field` instance.
(cherry picked from commit acb78eeb7a)
This PR fixes a parameter mismatch in the `apiClientFactory` function documentation example. The factory was previously passing only http and `userService` to the ``ApiClient`` constructor, but the constructor actually requires http, `baseUrl`, and `rateLimitMs` as separate parameters.
Key Changes:
Extracts baseUrl and rateLimitMs from UserService using getter methods
Updates the ApiClient instantiation to pass all three required constructor parameters
Adds a comment explaining the assumption about UserService providing these values
(cherry picked from commit 6f716e400e)
The regex for caching generated files in firebase.json has been updated to
include lowercase letters and underscores in the 8-character hash. This
ensures that files with names like `chunk-CrXHmw_W.js` are correctly
cached.
(cherry picked from commit e840cd547d)
In cases the `ngDevMode` flag hasn't been set, still enable the formatter. What matters is if `ngDevMode` is `false ` we tree shake that away.
(cherry picked from commit 1b895fece6)
Add an `AbortSignal` parameter to `Debouncer`. Implementations may
choose to accept this parameter to be informed when a debounced
operation is aborted. This may be useful for canceling pending timers or
avoiding unnecessary work.
(cherry picked from commit 98ce9a7b17)
Replaced the <docs-code> wrapper with a Markdown fenced code block to improve
copy/paste usability, syntax highlighting consistency, and alignment with current
documentation formatting standards.
Inspired by #65043
(cherry picked from commit 3cfd4361a5)
Replaced the <docs-code> wrapper with a Markdown fenced code block to improve
copy/paste usability, syntax highlighting consistency, and alignment with current
documentation formatting standards.
Inspired by angular#65043
(cherry picked from commit caaa5ec8e6)
This commit introduces a new guide for migrating existing Angular projects from Karma/Jasmine to Vitest.
The guide covers:
- Manual steps for installing dependencies and updating `angular.json`.
- Handling custom `karma.conf.js` configurations.
- Removing Karma-related files and packages.
- Configuring browser mode for Vitest.
- Details on the `refactor-jasmine-vitest` schematic for automated test refactoring.
The guide also clarifies that while Vitest is the default for new projects, migration for existing projects is experimental. It emphasizes reviewing changes and provides guidance on adapting custom Karma configurations to Vitest.
Renames `experimental-unit-test.md` to `migrating-to-vitest.md` and updates `sub-navigation-data.ts` accordingly.
(cherry picked from commit 258c295b92)
Reworks the way we approach type checking of signal forms to be closer to the behavior at runtime. There are a couple of scenarios that we handle:
1. For native controls, we now produce simplified type checking code that looks as follows:
```
var t1 = null! as number | string; // Type depends on the input `type`.
t1 = someField().value();
```
2. For custom controls we generate bindings to the individual inputs, rather than checking conformance against `FormValueControl`/`FormCheckboxControl`. This is closer to the behavior at runtime and it allows us to handle generic directives properly.
(cherry picked from commit f7e58577a4)
Angular Robot