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
This commit moves the foreign function resolver logic for detecting a
`ModuleWithProviders` in a return type position of a function call, as the logic can
then be reused for standalone components in a subsequent commit.
PR Close#46009
tweak the current structural directives guide (currently mainly targeted
at the creation of custom structural directives) so that is more generic
and a point of reference for structural directives in general
this also includes the re-addition of the one-per-element section
removed in PR #40015resolves#44786
PR Close#44895
The formatting of the `babel_ast_host.ts` file is invalid due to a
recently-merged PR. The PR had a passing `lint` state but this seemed
to just appear like this because the Git comparison range on upstream
branches can become invalid (due to a known bug in CircleCI -- reported)
PR Close#46082
update the error message presented during aot compilation when an unrecognized
tag/element is found in a standalone component so that it does not mention
the ngModule anymore
Note: the jit variant is present in PR #45920resolves#45818
PR Close#45919
Currently for cases when an unknown structural directive is applied to `<ng-template>`s, an error message thrown by the framework doesn't contain a tag name, for example:
```
NG0303: Can't bind to 'unknownDir' since it isn't a known property of 'null'.
```
The underlying reason is that the tag name for the `<ng-template>` is not produced (`null` is useed as a value) by the compiler in case of inline templates and runtime logic relies on this effect.
This commit handles this situation when an error message is thrown, as the fastest way to improve the error message. More refactoring would be needed to avoid relying on the mentioned effect at runtime.
PR Close#46068
update the error message presented during jit compilation when an unrecognized
tag/element is found in a standalone component so that it does not mention
the ngModule anymore
Note: the aot variant is present in PR #45919resolves#45818
PR Close#45920
Previously, the code in TestBed didn't take into account the fact that the `cmp.dependencies` array after the AOT compilation might contain regular (NgModule-based) Components/Directive/Pipes. As a result, some NgModule-specific code paths were invoked for non-NgModule types, thus leading to errors.
This commit updates the code to handle AOT-compiled structure of standalone components correctly.
PR Close#46052
This commit updates the NgModule logic to account for a case when a type has more than one generated def. This is a common situation for NgModules which have at least two: ɵmod and ɵinj. Previously, the second def was not stored before applying overrides, thus leaving it modified after the test, leaking the state as a result. This fix ensures that we store all defs before applying any overrides.
PR Close#46049
This commit accounts for the Babel types changes. Some properties
can now also be `undefined` so existing checks/assertions had to
be adjusted to also capture `undefined` (along with `null`).
Additionally, in preparation for a new ECMA proposal, Babel types
seem to have been updated to include private names in object property
keys. This is not necessarily the case for object expressions, but
could be for object patterns (in the future -- when implemented).
More details: https://github.com/babel/babel/pull/14304 and
https://github.com/tc39/proposal-destructuring-private.
PR Close#45967
We recently updated Babel and the Bazel types but this actually
resulted in duplicates, causing differences between what people
seen in their IDE vs. what Bazel builds.
This commit removes the lock file and generates it fully fresh,
deduping dependencies and also fixing the differences between
local IDE and Bazel.
As part of this we also need to update/fixup one assertion on the
Babel node path types, because the node start/end can now also
be `undefined`.
PR Close#45967
DEPRECATED:
It is now deprecated to provide *both* `AbstractControlOption`s and an async validators argument to a FormControl. Previously, the async validators would just be silently dropped, resulting in a probably buggy forms. Now, the constructor call is deprecated, and Angular will print a warning in devmode.
DEPRECATED:
The `initialValueIsDefault` option has been deprecated and replaced with the otherwise-identical `nonNullable` option, for the sake of naming consistency.
In some places, the [@see][1] JSDoc tag was incorrectly used instead of
the [@link][2] inline tag, leading to warnings during doc generation and
the `@see` tags being ignored (and thus shown in the docs as is).
Replace the `@see` tags with the intended `@link` tags.
[1]: https://jsdoc.app/tags-see.html
[2]: https://jsdoc.app/tags-inline-link.html
PR Close#46040
Adds additional tests to verify `enabledBlocking` functionality. The
initial attempt to fix#44355 would have broken the scenario where a new
navigation cancels the initial navigation. We also cannot rely on
`NavigationError` like the example workaround in that issue report is
doing because there won't be one if a guard simply rejects
the initial nav (#16211).
PR Close#45733
This commit fixes a small issue in the logic around the calculation of
template scopes for standalone components. These scopes include a
`Reference` for each dependency of a standalone component, which is used to
generate references to that dependency in various contexts.
Previously, the `Reference` used for a dependency was the one generated from
its own metadata. For example, a referenced directive used the `Reference`
that was created when analyzing the directive declaration itself. This still
works, as the compiler is always able to emit a reference to any valid
`Reference`. However, it's not optimal.
The `Reference` which should be used instead is the one generated from
analyzing the standalone component's `imports` array, which has knowledge of
how the dependency is referenced from within the standalone component's file
itself. This allows the compiler to skip creating a new import for the
dependency when emitting the standalone component, and use the existing,
user-authored import instead. This saves on code size and avoids taxing the
bundler with unnecessary imports.
PR Close#46029
The Angular compiler performs cycle detection when generating imports within
component files. This was previously necessary as reifying dependencies
discovered via NgModules into the component output could add imports that
weren't present in the original component and potentially create cycles.
Doing this could cause order-of-execution issues with existing user imports,
so the compiler detects this case and falls back to an alternative way of
specifying component dependencies that doesn't risk creating cycles.
For standalone components, Angular does not need to add new imports to the
component file as the user has already explicitly referenced dependencies
in the `@Component.imports`. As a result, the cycle detection can be
skipped.
Correctly authoring a program with import cycles is always challenging. One
side of a cyclic import will always initially evaluate to `undefined`, and
this can result in errors in the component definition when this happens
within component `imports`.
Our compiler _could_ detect the cycle and choose to wrap the component
dependencies in an automatic closure instead, avoiding any issues with
`undefined` during an eager evaluation. However, this commit makes an active
choice not to do that as it only serves to mask the problems with cyclic
imports. Future refactorings may cause the "other half" of the cycle to
break. Users should instead be aware of the potential problems with cycles
and explicitly defer evaluations with `forwardRef` where needed. This
ensures that future implementations of Angular compilation which may not be
able to automatically detect import cycles and correct accordingly can still
compile such components.
PR Close#46029
* `FormRecord` jsdocs should now appear on a.io
* The `{@see foo#bar}` syntax previously did not work, and has been replace with backticks
PR Close#46023
Consider a typed group for storing contact information:
```
declare interface ContactControls {
name: FormControl<string|null>;
}
contactForm: FormGroup<ContactControls> = ...;
saveForm(form: FormGroup<ContactControls>) {
service.newContact(contactForm.value);
}
```
What should be the type of `newContact`? The answer, of course, is the value type:
```
declare interface Contact {
name: string|null;
}
class ContactService {
newContact(c: Contact) {}
}
```
This is quite redundant, and therefore, we should allow the value type to be generated automatically. We already have the helper types to do this -- we just need to document and export them. Then, this becomes possible:
```
class ContactService {
newContact(c: RawValue<FormGroup<ContactControls>>) {}
}
```
PR Close#45978
This commit adds the `ngDevMode` check to tree-shake away an error message string (which also retains a reference to an extra function).
PR Close#45994
Currently, the `Router` will create the `EnvironmentInjector` for a
`Route` with `providers` as soon as it _attempts_ to match segments to
the `Route`. Instead, this change updates the logic to only create the
injector once we have confirmed that the `Route` matches. Note that this
will include partial matches where the final navigation still fails with
a "cannot match any routes to segment" error. We need to maintain the
injector hierarchy so we still need to create parent injectors before
descending into the child routes and determining if there is a full
match or just a partial one.
resolves#45988
PR Close#45990
The `inject()` function was introduced with Ivy to support imperative
injection in factory/constructor contexts, such as directive or service
constructors as well as factory functions defined in `@Injectable` or
`InjectionToken`. However, `inject()` in a component/directive constructor
did not work due to a flaw in the logic for creating the internal factory
for components/directives.
The original intention of this logic was to keep `ɵɵdirectiveInject` tree-
shakable for applications which don't use any component-level DI. However,
this breaks the `inject()` functionality for component/directive
constructors.
This commit fixes that issue and adds tests for all the various cases in
which `inject()` should function. As a result `ɵɵdirectiveInject` is no
longer tree-shakable, but that's totally acceptable as any application that
uses `*ngIf` or `*ngFor` already contains this function. It's possible to
change how `inject()` works to restore this tree-shakability if needed.
PR Close#45991
This change adds the capability of ngc_wrapped to emit an
unused_inputs_list file that could be used by starlark.
We are making this change because in situations where angular modules
depend on angular modules, it becomes very easy for a single change to
trigger a long cascading set of angular builds since each angular rule
depends on the transitive closure of input files.
With this change in place, and once it is properly configured, bazel
will update the set of inputs to a build rule after it is built once
removing any of the inputs specified in this list, making incremental
builds quicker by skipping any rebuilds that only had changes to unused
inputs.
This logic should be, and is likely duplicated in tsc_wrapped to solve
the same problem in pure TypeScript situations, ideally we could use the
same implementation one day.
In addition, its possible that tree artifacts are not as supported as
we'd like, and where this change should mark entire directories as
unused, we may get better performance gains by enumerating the directory
and being more explicit about specific inputs which are unused.
PR Close#45946
This commit updates the Testability-related tests to reset the testability getter class after each test to avoid leaking the state between tests. This should improve the stability of the testability tests that are currently flaky on CI.
PR Close#45947
The Testability-related logic was refactored in https://github.com/angular/angular/pull/45657 to become tree-shaking-friendly: it was decoupled from the core providers of the `BrowserModule`. This commit updates the newly-introduced `bootstrapApplication` function to exclude Testability-providers by default (note: the Testability is still included in the NgModule-based bootstrap).
In order to add the Testability to the app bootstrapped via `bootstrapApplication`, the `provideProtractorTestingSupport` function is introduced.
PR Close#45885
Previously, using `FormBuilder` with a union type would produce unions of *controls*:
```
// `foo` has type `FormControl<string>|FormControl<number>`.
const c = fb.nonNullable.group({foo: 'bar' as string | number});
```
This actually works in many cases, due to how extraordinarily powerful Typescript's distributive types are (e.g. `value` still has type `string|number`), but it is subtly incorrect. Here is a code example that exposes the reason the inference is incorrect. It exploits the fact that Typescript will not "un-distribute" a type, producing an obviously spurious error:
```
// fc gets an inferred distributive union type `FormControl<string> | FormControl<number>`
let fc = c.controls.foo;
// Error: Type 'FormControl<string | number>' is not assignable to type 'FormControl<string> | FormControl<number>'.
fc = new FormControl<string|number>('', {initialValueIsDefault: true});
```
Instead, we want the union to apply to the *values*:
```
// `foo` should have type `FormControl<string|number>`.
const c = fb.nonNullable.group({foo: 'bar' as string | number});
```
Essentially, we want to prevent Typescript from distributing the type. [As specified in the handbook](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#distributive-conditional-types):
> Typically, distributivity is the desired behavior. To avoid that behavior, you can surround each side of the extends keyword with square brackets.
This PR applies this suggestion to `FormBuilder`'s type inference.
Fixes#45912.
PR Close#45942
We've had a TODO to expose ManualOnPush for a long time, but it hasn't moved since then. These changes remove it since it would be easy to re-introduce if we wanted to, it frees up an extra space in the flags bitmap and it removes some `render3` tests that we won't have to migrate to `TestBed`.
PR Close#45943
When an external template is read, adds the template file to to the project which contains.
This is necessary to keep the projects open when navigating away from HTML files.
Since a `tsconfig` cannot express including non-TS files,
we need another way to indicate the template files are considered part of the project.
Note that this does not ensure that the project in question _directly_ contains the component
file. That is, the project might just include the component file through the program rather
than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important
because the TypeScript language service/server prefers projects which _directly_ contain the TS
file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can
possibly be a different project used between the TS and HTML files.
For example, in Nx projects, the referenced configs are `tsconfig.app.json` and
`tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and
contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS
files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files
but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot
effectively express `projectContainsInfoDirectly` for HTML files.
We could consider also updating the language server implementation to attempt
to select the project to use for the template file based on which project
contains its component file directly, using either the internal `project.projectContainsInfoDirectly`
or as a workaround, check `project.isRoot(componentTsFile)`.
Finally, keeping the projects open is hugely important in the solution style config case like
Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not
`tsconfig.app.json`. However, if our extension does not also know to select
`tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined
first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in
keeping projects open when there is an HTML file open and (2) optionally attempt to do this
_only_ for projects that we know the TS language service will prioritize in TS files (i.e.,
attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close)
and prioritize that project for all requests.
fixes https://github.com/angular/vscode-ng-language-service/issues/1623
fixes https://github.com/angular/vscode-ng-language-service/issues/876
PR Close#45601
Based on early feedback, calling `fb.nonNullable.group(...)` continues to be clunky for a form with many such groups. Allowing `NonNullableFormBuilder` to be directly injected enables the following:
```
constructor(private fb: NonNullableFormBuilder) {}
```
PR Close#45904
This allows the documentation for the options `errorOnUnknownElements` and `errorOnUnknownProperties` to be displayed in the docs.
They aren't currently displayed, as `TestModuleMetadata` is a type and not an interface.
See https://next.angular.io/api/core/testing/TestModuleMetadata
PR Close#45891
In PR #45405, the Angular Package Format (APF) was updated so that
secondary entry-points (such as `@angular/common/http`) do not have
their own `package.json` file, as they used to. Instead, the paths to
their various formats and types are exposed via the primary
`package.json` file's `exports` property. As an example, see the v13
[@angular/common/http/package.json][1] and compare it with the v14
[@angular/common/package.json > exports][2].
Previously, `ngcc` was not able to analyze such v14+ entry-points and
would instead error as it considered such entry-points missing.
This commit addresses the issue by detecting this situation and
synthesizing a `package.json` file for the secondary entry-points based
on the `exports` property of the primary `package.json` file. This data
is only used by `ngcc` in order to determine that the entry-point does
not need further processing, since it is already in Ivy format.
[1]: https://unpkg.com/browse/@angular/common@13.3.5/http/package.json
[2]: https://unpkg.com/browse/@angular/common@14.0.0-next.15/package.json
PR Close#45833
Move the `loadPackageJson()` helper (and associated generic types, such
as `JsonObject`) from `packages/entry_point.ts` to `utils.ts` and also
rename it to `loadJson()`. This way, they can be used in other places in
future commits, without introducing cyclical dependencies.
PR Close#45833
Speeds up the `d.ts` bundling by configuring it as a Bazel
persistent worker. Also improve logging for the ng packager
rule to make it easier to spot which actions/bundles take
up significant time.
Type bundling will occur for every entry-point so for machines
with rather limited cores/threads, this will be useful to save
NodeJS boot and resolution time.
PR Close#45900
This commit refactors the `Testability`-related logic to extract the necessary providers into a separate array, so that it can later become it's own NgModule (or exposed as an array of providers) and be excluded from the new APIs by default.
PR Close#45657
This commit renames an internal function that implements the core bootstrap logic. The function is exported as a private symbol (with `ɵ`), but in order to avoid any possible confusion, we include "internal" into the function name as well.
PR Close#45896
dario-piotrowicz