Refs #42966.
This moves extended template check factory invocations into the checker itself, where it can provide a more consistent API contract. Factories are called with compiler options and may return a `TemplateCheck` or `undefined` if the current options do not support that check. This allows `nullishCoalescingNotNullable` to disable itself when `strictNullChecks` is disabled without throwing errors. This gives extended template diagnostics a stronger abstraction model to define their behavior with.
PR Close#44391
Refs #42966.
The enum of extended template diagnostic names allows a global registry of first-party diagnostics with a developer-friendly string name which can be used for configuration. This name is used in the new `TemplateCheckFactory` to bind the name to a particular `ErrorCode` and make both available *before* constructing the actual template check, which is necessary to configure it appropriately.
PR Close#44391
In `language-service`, the `checker.getDirectiveMetadata` doesn't return the animations meta of the `Component`.
but it's useful for animation completion.
PR Close#44630
The changes in 2028c3933f caused method
calls to be emitted using additional parenthesis into the TCB, which in
turn prevented proper type narrowing when the method acts as a type
guard. This commit special-cases method calls from property reads to
avoid the additional parenthesis.
Fixes#44353
PR Close#44447
This was flagged during the code review of #44580. When generating a type check block, we were interpreting any call to `$any` as an `as any` cast, even if it's part of a `PropertyRead` (e.g. `foo.$any(1)`). This is handled correctly in other parts of the compiler, but it looks like it was missed in the type checker.
PR Close#44657
This page exists in the most recent angular.io version (v13 currently), so there's no need to link to an old version. The hash also refers to the title section of the page, which isn't necessary and is now dropped.
PR Close#44649
Dev mode output was switched from ES5 -> ES2015 recently and as a part of those changes, some target names that contained `_es5` postfixes were changes to `_es2015` instead. This commit fixes the issue with one of the recently merged BUILD files that contained the old (`_es5`) postfix.
PR Close#44651
When building a library, the `rootDir` option is configured to ensure
that all source files are present within the entry-point that is being
build. This imposes an extra constraint on the reference emit logic,
which does not allow emitting a reference into a source file outside of
this `rootDir`.
During the generation of type-check blocks we used to make a best-effort
estimation of whether a type reference can be emitted into the
type-check file. This check was relaxed in #42492 to support emitting
more syntax forms and type references, but this change did not consider
the `rootDir` constraint that is present in library builds. As such, the
compiler might conclude that a type reference is eligible for emit into
the type-check file, whereas in practice this would cause a failure.
This commit changes the best-effort estimation into a "preflight"
reference emit that is fully accurate as to whether emitting a type
reference is possible.
Fixes#43624
PR Close#44587
The `NgtscCompilerHost` is implemented using the `FileSystem`
abstraction of the compiler, which is implemented for tests using an
in-memory `MockFileSystem`. If the in-memory filesystem contains
symlinks, then using `NgtscCompilerHost` would not reflect their
resolved real path. Instead, the TypeScript compiler would use its
default implementation based on the real filesystem, which is unaware of
the in-memory `MockFileSystem` setup.
This change does not currently address any issues, but is being fixed
as it prevented a reproduction scenario from behaving correctly.
PR Close#44587
In certain scenarios, the compiler may have crashed with an
`Unable to write a reference` error which would be particularly hard
to diagnose. One of the primary reasons for this failure is when the
`rootDir` option is configured---typically the case for libraries---
and a source file is imported using a relative import from an external
entry-point. This would normally report TS6059 for the invalid relative
import, but the crash prevents this error from being surfaced.
This commit refactors the reference emit logic to result in an explicit
`Failure` state with a reason as to why the failure occurred. This state
is then used to report a `FatalDiagnosticException`, preventing a hard
crash.
Closes#44414
PR Close#44587
This commit moves some logic to make the location of runtime error codes consistent across packages. Now all error codes are located in `packages/core/src/errors.ts` file.
PR Close#44398
To make our test output i.e. devmode output more aligned
with what we produce in the NPM packages, or to be more
aligned with what Angular applications will usually consume,
the devmode output is switched from ES5 to ES2015.
Additionally various tsconfigs (outside of Bazel) have been
updated to match with the other parts of the build. The rules
are:
ES2015 for test configurations, ES2020 for actual code that will
end up being shipped (this includes the IDE-only tsconfigs).
PR Close#44505
The Ivy compiler no longer generates code for type-checking purposes
using the output AST types. Instead, it uses TypeScript AST nodes and
its printer for type-checking. This commit removes the type-related
output nodes.
PR Close#44411
The `ng_rollup_bundle` rule has been replaced with a new rule called
`app_bundle`. This rule replicates the Angular v13 optimization
pipeline in the CLI, so that we can get better benchmarking results.
Also the rule is much simpler to maintain as it relies on ESbuild.
The old `ng_rollup_bundle` rule did rely on e.g. build-optimizer that no
longer has an effect on v13 Angular packages, so technically size
tests/symbol tests were no longer as correct as they were before. This
commit fixes that.
A couple of different changes and their explanation:
* Language-service will no longer use the benchmark rule for creating
its NPM bundles! It will use plain `rollup_bundle`. ESBuild would have
been nice but the language-service relies on AMD that ESBuild cannot
generate (yet?)
* Service-worker ngsw-worker.js file was generated using the benchmark
bundle rule. This is wrong. We will use a simple ESbuild rule in the
future. The output is more predictable that way, and we can have a
clear use of the benchmark bundle rule..
* A couple of benchmarks in `modules/` had to be updated to use e.g.
`initTableUtils` calls. This is done because with the new rule, all
files except for the entry-point are considered side-effect free. The
utilities for benchmarks relied on side-effects in some
transitively-loaded file (bad practice anyway IMO). We are now
initializing the utilities using a proper init function that is
exported...
PR Close#44490
Cleans up some of the temporary workarounds that were necessary in order to land support for TypeScript 4.5 since they're no longer necessary.
PR Close#44477
Now that ViewEngine libraries can no longer be created, the latest
TypeScript version that ngcc should be able to process is TypeScript 4.3,
i.e. the version of TypeScript that was supported in Angular 12.
However, ngcc's integration tests used the TypeScript version of the
workspace to create the JavaScript files from TypeScript sources on
demand. This introduces friction when upgrading the TypeScript version
within the workspace, as changes to TypeScript's emit format may affect
ngcc's ability to process it correctly.
The on demand creation of JavaScript files was convenient for authoring
tests, but it also helped to detect incompatibilities with newer
versions of TypeScript. Now that ngcc no longer has to process newer
versions of TypeScript, we want to pin the integration suite to use
JavaScript code as if it were compiled using TypeScript 4.3, i.e. a
version of TypeScript that is actually supported by ngcc.
This commit updates the integration test to inline all the generated
files directly in the tests, instead of compiling them on demand. This
was done by temporarily installing TypeScript 4.3 and using it to create
the `loadTestFiles` statement from the original TypeScript inputs.
An alternative could have been to install TypeScript 4.3 as an actual
dependency in the workspace and using that to continue compiling the
integration suite on demand, but this brings some overhead in package
installations (TypeScript is ~60MB) and the authoring aspect of ngcc
integration test is expected to diminish, now that ngcc's support is no
longer a moving target.
PR Close#44448
As mentioned in the previous commit, integration tests will be declared
in subpackages of `//integration`. For these tests to still rely on the
NPM packages from `HEAD`, we need to update the visibility.
PR Close#44238
Previously, when processing UMD, ngcc assumed that the `exports`
argument of the CommonJS factory call (if present) would be the first
argument of the call. This is generally true for the supported UMD
formats, but can change if ngcc prepends more imports (and thus factory
arguments) while processing the module. This could lead to errors when
trying to collect dependencies of an already processed module.
(This was accidentally broken in #44245 (commit 2bc3522e16).)
This commit fixes it by not making any assumptions about the position of
an `exports` argument in the CommonJS factory call.
Fixes#44380
PR Close#44381
This commit finishes the removal of View Engine from the codebase, deleting
those pieces of @angular/compiler which were only used for VE.
Co-Authored-By: JoostK <joost.koehoorn@gmail.com>
PR Close#44368
This commit does a first-pass removal of the View Engine infrastructure
in compiler-cli. A more in-depth cleanup is necessary and large parts
of the View Engine compiler infrastructure remain within
`@angular/compiler`, this is just a first cleanup step.
PR Close#44269
As a preparation for the removal of the ViewEngine parts in
`compiler-cli`, this commit moves the version number helper functions
up one level such that the whole `diagnostics` subfolder can be removed.
PR Close#44269
Adds support for TypeScript 4.5. Includes the following changes:
* Bumping the package versions.
* Fixing a few calls to `createExportSpecifier` and `createImportSpecifier` that require an extra parameter.
* Adding some missing methods to the TS compiler hosts.
* Fixing an issue in the TS mocks for the ngcc tests where a regex was too agressive and was trying to match a path like `/node_modules/@typescript/lib-es5`.
* Accounting for type-only import specifiers when reporting DI errors (see #43620).
Fixes#43620.
PR Close#44164
The downlevel decorator transform (commonly used in the CLI and other
tooling of the ecosystem for enabling JIT ES2015+), is currently
incorrectly dealing with nested classes.
The transform will accidentally visit nested classes (in a constructor)
multiple times and generate duplicated instances of the `ctorParameters`
fields. This does not sound like an issue at first, but the duplicated
`ctorParameters` fields will miss significant type information that has
been elided by the first visit, resulting in generated code like the
following:
```js
let MyClass = /* @__PURE__ */ __name(class MyClass extends UpgradeNg1ComponentAdapter {
constructor(scope, injector3, elementRef) {
}
}, "MyClass");
MyClass.ctorParameters = () => [
{ type: void 0, decorators: [{ type: Inject, args: [$SCOPE] }] },
{ type: Injector },
{ type: ElementRef }
];
MyClass.ctorParameters = () => [
{ type: void 0 }, // <---- NOTE!
{ type: Injector },
{ type: ElementRef }
];
```
PR Close#44281
Previously, the mock packages created for `UmdDependencyHost`'s tests,
specified the entry-point as `esm2015`. This does not matter in tests,
since the packages are explicitly passed to the `UmdDependencyHost`
(while in reality the appropriate host would be determined based on the
name of the entry-point property - in this case, detecting the
entry-point as ES2015 and not UMD).
However, in order to avoid confusion, this commit updates the test
packages to use `main` (the default property used for the UMD format in
`package.json` files).
PR Close#44245
Previously, the ngcc `UmdReflectionHost` would throw a misleading error
when trying to collect dependencies of an invalidly formatted UMD
module. This happened because an error would be thrown while trying to
construct the error message for the actual error, by calling `getText()`
on certain TypeScript AST nodes. See
https://github.com/angular/angular/issues/44019#issuecomment-959954121
for a more in-depth explanation.
This commit ensures `getText()` can be safely called on TypeScript AST
nodes when collecting dependencies of UMD modules.
PR Close#44245
This commit utilizes the infrastructure added in the previous commit to
run more tests against more of the supported UMD formats. This shall
give us more confidence that all aspects of UMD processing work
correctly with the various formats.
PR Close#44245
Previously, several ngcc test suites used their own helper to generate
test UMD modules.
This commit switches to using the same helper for generating UMD modules
across test suites. This improves DRYness (ensuring changes/fixes to the
UMD format need only be applied once) and makes it easier to test
different UMD formats in all test suites.
PR Close#44245
Previously, ngcc could only handle UMD modules whose wrapper function
was implemented as a `ts.ConditionalExpression` (i.e. using a ternary
operator). This is the format emitted by popular bundlers, such as
Rollup.
This commit adds support for a different format, that uses `if/else`
statements, which is what is [emitted by Webpack][1].
[1]: https://webpack.js.org/configuration/output/#type-umdFixes#44019
PR Close#44245
Previously, ngcc could only handle UMD modules whose wrapper function
was implemented as a `ts.ConditionalExpression` (i.e. using a ternary
operator). This is the format emitted by popular bundlers, such as
Rollup. However, this failed to account for a different format, using
`if/else` statements, such as the one [emitted by Webpack][1].
This commit prepares ngcc for supporting different UMD wrapper function
formats by decoupling the operation of parsing the wrapper function body
to capture the various factory function calls and that of operating on
the factory function calls (for example, to read or update their
arguments). In a subsequent commit, this will be used to add support for
the Webpack format.
[1]: https://webpack.js.org/configuration/output/#type-umd
PR Close#44245
This commit removes special functions that were used to run tests in ViewEngine or Ivy only.
Since ViewEngine is deprecated and we no longer run ViewEngine tests on CI, we can cleanup
those special helpers and ViewEngine-only tests.
PR Close#44120
ngcc used to rewrite `PRE_R3` markers to become `POST_R3` in order to
switch the runtime implementation in `@angular/core` from View Engine to
Ivy. Now that `@angular/core` is published as native Ivy package and the
runtime switch code has been removed, there is no need for ngcc to
perform this transform anymore.
PR Close#43891
Now that the core package has been cleaned up to no longer contain Ivy
switch code, the transform to switch the `PRE_R3` markers to become
`POST_R3` is deleted as well.
PR Close#43891
This commit removes the View Engine runtime. Itself, this change is
relatively straightforward, but it represents the final step in a multi-year
journey. It's only possible due to the hard work of many current and former
team members and collaborators, who are too numerous to list here.
Co-authored-by: Alan Agius <alan.agius4@gmail.com>
Co-authored-by: Andrew Kushnir <akushnir@google.com>
Co-authored-by: Andrew Scott <atscott01@gmail.com>
Co-authored-by: Andrew Seguin <andrewjs@google.com>
Co-authored-by: Cédric Exbrayat <cedric@ninja-squad.com>
Co-authored-by: Charles Lyding <19598772+clydin@users.noreply.github.com>
Co-authored-by: Dave Shevitz <dshevitz@google.com>
Co-authored-by: Doug Parker <dgp1130@users.noreply.github.com>
Co-authored-by: Dylan Hunn <dylhunn@gmail.com>
Co-authored-by: Emma Twersky <emmatwersky@google.com>
Co-authored-by: George Kalpakas <kalpakas.g@gmail.com>
Co-authored-by: Igor Minar <iminar@google.com>
Co-authored-by: Jeremy Elbourn <jelbourn@google.com>
Co-authored-by: Jessica Janiuk <jessicajaniuk@google.com>
Co-authored-by: JiaLiPassion <JiaLi.Passion@gmail.com>
Co-authored-by: Joey Perrott <josephperrott@gmail.com>
Co-authored-by: Joost Koehoorn <joost.koehoorn@gmail.com>
Co-authored-by: Kristiyan Kostadinov <crisbeto@abv.bg>
Co-authored-by: Madleina Scheidegger <mscheid@google.com>
Co-authored-by: Mark Thompson <2554588+MarkTechson@users.noreply.github.com>
Co-authored-by: Minko Gechev <mgechev@gmail.com>
Co-authored-by: Paul Gschwendtner <paulgschwendtner@gmail.com>
Co-authored-by: Pawel Kozlowski <pkozlowski.opensource@gmail.com>
Co-authored-by: Pete Bacon Darwin <pete@bacondarwin.com>
Co-authored-by: Wagner Maciel <wagnermaciel@google.com>
Co-authored-by: Zach Arend <zachzach@google.com>
PR Close#43884
This commit removes most tests that were designated as only covering View
Engine code. It also removes tag filters from CI and local commands to run
tests.
In a few cases (such as with the packages/compiler tests), this tag was
improperly applied, and certain test cases have been added back running in
Ivy mode.
This commit also empties `@angular/compiler/testing` as it is no longer
necessary (this is safe since compiler packages are not public API). It can
be deleted in the future.
PR Close#43884
When executing, ngcc writes a lock-file that is used to coordinate multiple concurrent instances of ngcc.
Previously, this file was written at `node_modules/@angular/compiler-cli/ngcc`, or similar depending upon the bundling of the package.
But this causes problems for setups where `node_modules` package directories are expected to be read-only.
Now, the lock-file is written as `.ngcc_lock_file` into the top of the `node_modules`, which is an acceptable place to store transient files.
This change should help to unblock use of tools like pnpm and lerna, which can use symlinks to readonly package directories.
PR Close#44228
These changes add support for interpreting `String.prototype.concat` calls. We need to support it, because in TypeScript 4.5 string template expressions are transpiled to `concat` calls, rather than string concatenations. See https://github.com/microsoft/TypeScript/pull/45304.
PR Close#44167
When a partially compiled component or directive is "linked" in JIT mode, the body
of its declaration is evaluated by the JavaScript runtime. If a class is referenced
in a query (e.g. `ViewQuery` or `ContentQuery`) but its definition is later in the
file, then the reference must be wrapped in a `forwardRef()` call.
Previously, query predicates were not wrapped correctly in partial declarations
causing the code to crash at runtime. In AOT mode, this code is never evaluated
but instead transformed as part of the build, so this bug did not become apparent
until Angular Material started running JIT mode tests on its distributable output.
This change fixes this problem by noting when queries are wrapped in `forwardRef()`
calls and ensuring that this gets passed through to partial compilation declarations
and then suitably stripped during linking.
See https://github.com/angular/components/pull/23882 and https://github.com/angular/components/issues/23907
PR Close#44113
Currently the TS version checking function interprets a version like `1.2.3-rc.5` as `1.2.NaN` which would allow it to bypass the version checking altogether.
These changes add a little bit more logic to ensure that such versions are handled correctly. There's also an error if we don't manage to parse the version string.
Also it seemed like we never actually ran the version check unit tests, because they didn't have a test target.
PR Close#44109
This commit adds additional information to encourage developers to contact
the author of View Engine libraries and ask them to update to partial Ivy.
Fixes#42308
PR Close#43996
Consider the `NgModel` directive which has the `ngModelOptions` input:
```ts
class NgModel {
@Input() ngModelOptions: { updateOn: 'blur'|'change'|'submit' };
}
```
In a template this may be set using an object literal as follows:
```html
<input ngModel [ngModelOptions]="{updateOn: 'blur'}">
```
This assignment should be accepted, as the object's type aligns with the
`ngModelOptions` input in `NgModel`. However, if the `strictNullInputTypes`
option is disabled this assignment would inadvertently produce an error:
```
Type '{ updateOn: string; }' is not assignable to type '{ updateOn: "blur"|"change"|"submit"; }'.
Types of property 'updateOn' are incompatible.
Type 'string' is not assignable to type '"blur"|"change"|"submit"'
```
This is due to the `'blur'` value being inferred to be of type `string`
instead of retaining its literal type. The non-null assertion operator
that is automatically inserted for input binding assignments when
`strictNullInputTypes` is disabled inhibits TypeScript from inferring
the string value as its literal type.
This commit fixes the issue by omitting the insertion of the non-null
operator for object literals and array literals.
PR Close#38305
