In Bazel worker-land, workers which use incremental compilation must still
emit all declared outputs and cannot rely on these outputs persisting from
previous builds.
This commit adds a flag to `performCompilation` which can be used by the
worker infrastructure to instruct the compiler to always emit all possible
output files, regardless of any incremental build optimizations.
PR Close#46355
An inline type-check block is required when a reference to a component class
cannot be emitted from an ngtypecheck shim file, but the logic to detect this
situation did not consider the configured `rootDir`. When a `rootDir` is
configured the reference emitter does not allow generating an import outside
this directory, which meant that a shim file wouldn't be able to reference
the component class. Consequently, type-check block generation would fail
with a fatal error that is unaccounted for, as gathering diagnostics should
be non-fallible.
This commit fixes the problem by leveraging the existing `canReferenceType`
logic of the type-checking `Environment`, instead of the rudimentary check
whether the class is exported as top-level symbol (`checkIfClassIsExported`).
Instead, `canReferenceType` pre-flights the generation of an import using the
`ReferenceEmitter` to tell exactly whether it will succeed or not; thus taking
into account the `rootDirs` constraint as well.
Fixes#44999
PR Close#46096
* beforePreactivation hook is unused
* The only place that uses afterPreactivation does not use the arguments
Not to say we won't want to provide hooks similar to this in the future,
but the current state is over-engineered for what it's being used for.
PR Close#46321
Saves us some bytes by not emitting `providers` in `defineInjector`. While the amount of bytes isn't huge, I think that this change is worthwhile, because `ng generate` currently generates `providers: []` with every `NgModule` which users can forget to remove.
PR Close#46301
`ngComponentOutlet` already handles null/undefined values, but the types don't reflect that. These changes update the types.
Fixes#45716.
PR Close#46280
This commit reuses the logic of the `withBody` helper and implements the `withHead` based on it.The helper method is useful for tests that rely on a certain tags being present in document's `<head>` element.
PR Close#46250
This commit renames the packages/private/testing/src/render3.ts -> packages/private/testing/src/utils.ts to avoid using the `render3` term as it used to differentiate VE and Ivy, which is no longer relevant.
PR Close#46250
This commit exports the `isHostComponentStandalone` function and also changes a location where it's imported from. The function was moved recently in a different PR, which caused some conflicts after merging other PRs that relied on the old structure.
PR Close#46274
`@angular/bazel` currently uses an older version of `@microsoft/api-extractor` which is causing downstream issues in Components. These changes bump up to a version that has a fix.
Context: https://github.com/angular/components/pull/25027
PR Close#46259
Consider the case in which `FormBuilder` is used to construct a group with an optional field:
```
const controls = { name: fb.control('') };
const foo: FormGroup<{
name: FormControl<string | null>;
address?: FormControl<string | null>;
}> = fb.group<{
name: FormControl<string | null>;
address?: FormControl<string | null>;
}>(controls);
```
Today, with fully strict TypeScript settings, the above will not compile:
```
Types of property 'controls' are incompatible.
Type '{ name: FormControl<string | null>; address?: FormControl<FormGroup<SubFormControls> | null | undefined> | undefined; }' is not assignable to type '{ name: FormControl<string | null>; address?: FormGroup<SubFormControls> | undefined; }'.
```
Notice that the `fb.group(...)` is calculating the following type for address: `address?: FormControl<FormGroup<string|null>`. This is clearly wrong -- an extraneous `FormControl` has been added!
This is coming from the calculation of the result type of `fb.group(...)`. In the type definition, if we cannot detect the outer control type, [we assume it's just an unwrapped value, and automatically wrap it in `FormControl`](https://github.com/angular/angular/blob/14.0.0/packages/forms/src/form_builder.ts#L66).
Because the optional `{address?: FormControl<string|null>}` implicitly makes the RHS have type `FormControl<string|null>|undefined`, [the relevant condition is not satisfied](https://github.com/angular/angular/blob/14.0.0/packages/forms/src/form_builder.ts#L55). In particular, the condition expects just `FormGroup<T>`, not `FormGroup<T>|undefined`. So we assume `T` is a value type, and it gets wrapped with `FormControl`.
The solution is to add the cases where `undefined` is included in the union type when detecting which control `T` is (if any).
PR Close#46253
Add info to the pipe not found error message so to give some help to the developer for
resolving the problem more efficiently
(Note: this change also distinguishes the case in which the hosting component is standalone)
PR Close#46247
split the single RuntimeError utils test testing about the correct
formatting of errors in multiple separate unit tests (for better
granularity and clearness)
PR Close#46239
the formatted error messages always include a period separator between the
provided error message and the find-more suffix, this is not always
desirable as it may add periods when they shoud not be, so improve the
formatting by checking and applying the period only if the provided message
doesn't end with a character which already represents a separator
additionally also improve the formatting by trimming the provided error
message
note that such trimming needs to be performed before the separator check
so that for example an error message like `"some error! "` doesn't produce
`"some error! ."` but it successfully produces "some error!"
PR Close#46239
It is currently unclear which directive to use for FormRecord. This commit amends the docs to explicitly state that the group directives can and should be used with records.
PR Close#46235
improve code regarding element validation by creating a new file
exporting validation functions and not exporting utils previously
globally available
PR Close#46175
This adds a test to illustrate the "canceling" behavior we get from the
`Observable` chain in the Router. A new navigation cancels ongoing ones,
and that means also preventing intermediate results in user guards from
executing. This test is important when thinking about future refactors
which might attempt to change the details of how the `applyRedirects`
operator executes.
PR Close#46231
We currently use all the ESM2020 and type sources as inputs for rollup
and type bundle actions, respectively. This is a source of slowness in
Bazel sandboxed builds because many unused files will be linked/made
available for many concurrently-running actions.
We should limit the inputs only to what is assumed to be used. We cannot
know exactly and need to include transitive types from `node_modules`,
but that is an inevitable construct with the current Bazel rules.
Note that the external node modules could still bring in a lot of files,
like in Material where the `.d.ts` files for all locales are brought
into the sandbox (from `@angular/common`). We likely would need to
remove these files in a postinstall for now, to speed up actions,
similar to how we did it for RxJS in all repositories. These are known
to be not used in the components repo.
PR Close#46187
To mitigate the effect of Observables with memory leak, this change clears
the `ChangeDetectorRef` when the `AsyncPipe` is destroyed. This avoids any
leak within the `Observable` to retain the view data. A test has been added
to verify that this change works correctly with promises that resolve _after_
the pipe has been destroyed.
Note: this is not marked as fix as `AsyncPipe` itself is _not_ leaking any
memory.
Closes#17624
PR Close#46128
The field's type does not account for the `null` value that is assigned
in the field's initializer. This commit includes `null` in the type for
better type-safety. Exising reads are updated with a non-null assertion
operation in places where initialization is known to have occurred.
PR Close#46128
Makes the following improvements in the runtime:
* Uses the unique ID of the component definition to keep track of its injector in the `StandaloneFeature`, instead of the definition itself. This reduces the amount of memory we can leak, if something doesn't get cleaned up.
* Changes the naming and description of the `ComponentDef.id` to reflect what it is used for.
PR Close#46093
There's some old logic in the error handler that tries to read an `ngErrorHandler` property off of the errors that are being logged. As far as I can tell, this is a ViewEngine leftover and it isn't actually being used anywhere.
PR Close#46216
In #45445 function inlining had to be disabled on one of our instructions, because Closure wasn't optimizing it correctly, causing an error at runtime. The error has been resolved so we can remove the deoptimization hint.
PR Close#46149
This commit adds the new `@developerPreview` tag to all of the standalone
component related APIs. With this, AIO will show an API status label which
links to the documentation on Developer Preview.
PR Close#46050
This commit updates the `bootstrapApplication` and the `importProvidersFrom` function docs with additional content that includes usage examples.
PR Close#46202
This makes a small update to the example so that it shows a use-case
that's not already covered by the 'enabled' option. The existing example
would get identical behavior to `scrollPositionRestoration: 'enabled'`
with `anchorScrolling: 'enabled'`.
The updated example shows a use-case for when custom scrolling _would_
be needed. For example, when data is fetched because it is not available
immediately or through a resolver. This is one of the cases described in #24547
This update is sufficient to address all of the documentation problems
noted in the aforementioned issue. Another fix should be made to address
the problem that scroll restoration needs to be delayed until after CD
has run so the update block of the activated component's template is
run.
PR Close#46201
This commit adds the Standalone guide link to the `@Component`, `@Directive` and `@Pipe` decorator properties related to standalone functionality to improve discoverability of the guide as well as providing extra context in API docs.
PR Close#46184
This commit updates the `inject` function docs by:
- rephrasing a description to include more usage cases
- adding usage examples
- making a function itself a public API (vs its alias const that was used previously)
PR Close#46168
This commit adds the component name into unknown element/property error message, so that it's easier to find a location of a template where the problem happened.
Closes#46080.
PR Close#46160
The MISSING_INJECTION_CONTEXT runtime error can be thrown when the
inject function is used outside of the class creation context.
Before this change we've only used a vague terms of the
'injection context'. This commit extends the error message to
indicate that we really talk about the class construction context.
PR Close#46166
This commit updates the error message to use correct info depending on whether a component is standalone or not. Previously we were always referring to @NgModules as a place to fix the issue, but not we also mention @Component when needed (for standalone components).
PR Close#46159
Angular generally supports cycles between components in the same NgModule.
We have a mechanism of moving the component scope declaration into the
NgModule file in this case. This ensures that Angular never itself
introduces an import which creates a cycle.
What happens if the cycle already exists in the user's program, though, is a
bit different. In these cases, the "correct" emit for Angular is to generate
the component scope (whether direct or remote) inside of a closure, to
prevent evaluating the scope's references until module evaluation is
complete and all cyclic imports have been resolved. We don't want to do this
for *all* scopes because the code size cost of emitting a function wrapper
is non-zero.
In this fix, we take the presence of a `forwardRef` in a component's
`imports` or in an NgModule `declarations` or `imports` as a sign that
component scopes emitted into those files need to be protected against
cyclic references. In a future commit, we may introduce a warning or error
if cyclic imports are not protected behind `forwardRef` in these cases, but
this will take some time to implement.
PR Close#46139
Prior to this commit, the error message that was produced for the unknown property situation, din't contain extra info on how the problem can be fixed. This commit adds more info to the error message and makes it similar to the one we use during the AOT compilation.
PR Close#46147
improve the error message developers get when adding a standalone
component in the TestBed.configureTestingModule's declarations array,
by making more clear the fact that this error originated from the
TestBed call
resolves#45923
PR Close#45999
Call tsc_wrapped's fileExists function instead of TypeScript's.
tsc_wrapped (used internally by ngc-wrapped) has an optimization under
bazel to avoid file system calls where possible. It takes advantage
bazelOpts.allowedInputs, which contains a list of all files available
for compilation.
File system calls can be quite slow depending on the file system. In
google3 I saw a 38 seconds compilation, which spent 6 seconds just doing
fs.stat calls during module resolution. Those fs.stat calls are entirely
gone after with this change.
PR Close#46069
This commit improves the reported error when importing e.g. `RouterModule.forRoot()`
from within `Component.imports`. Such import is not supported, as standalone components
can only refer to other standalone entities or NgModules in their `imports` array;
`ModuleWithProviders` are not supported as `Component.imports` is meant to be used
for the compilation scope of the component, _not_ for configuring DI.
Closes#46003
PR Close#46009
Alex Rickabaugh