Create getter methods `getXXXDef` for each definition which
uses `hasOwnProperty` to verify that we don't accidently read form the
parent class.
Fixes: #24011Fixes: #25026
PR Close#25736
Previously, if ngtsc encountered a VariableDeclaration without an
initializer, it would assume that the variable was undefined, and
return that result.
However, for symbols exported from external modules that resolve to
.d.ts files, variable declarations are of the form:
export declare let varName: Type;
This form also lacks an initializer, but indicates the presence of an
importable symbol which can be referenced. This commit changes the
static resolver to understand variable declarations with the 'declare'
keyword and to generate references when it encounters them.
PR Close#25775
The bootstrap property of @NgModule was not previously compiled by
the compiler in AOT or JIT modes (in Ivy). This commit adds support
for bootstrap.
PR Close#25775
Closure requires @nocollapse on Ivy definition static fields in order
to not convert them to standalone constants. However tsickle, the tool
which would ordinarily be responsible for adding @nocollapse, doesn't
properly annotate fields which are added synthetically via transforms.
So this commit adds @nocollapse by applying regular expressions against
code during the final write to disk.
PR Close#25775
`ngcc` adds marker files to each folder that has been
compiled, containing the version of the ngcc used.
When compiling, it will ignore folders that contain these
marker files, as long as the version matches.
PR Close#25557
Closure compiler requires that the i18n message constants of the form
const MSG_XYZ = goog.getMessage('...');
have names that are unique across an entire compilation, even if the
variables themselves are local to a given module. This means that in
practice these names must be unique in a codebase.
The best way to guarantee this requirement is met is to encode the
relative file name of the file into which the constant is being written
into the constant name itself. This commit implements that solution.
PR Close#25689
TypeScript has a more modern diagnostic emit function which produces
contextually annotated error information, using colors in the console
to indicate where in the code the error occurs.
This commit swiches ngtsc to use this format for diagnostics when
emitting them after a failed compilation.
PR Close#25647
This commit takes the first steps towards ngtsc producing real
TypeScript diagnostics instead of simply throwing errors when
encountering incorrect code.
A new class is introduced, FatalDiagnosticError, which can be thrown by
handlers whenever a condition in the code is encountered which by
necessity prevents the class from being compiled. This error type is
convertable to a ts.Diagnostic which represents the type and source of
the error.
Error codes are introduced for Angular errors, and are prefixed with -99
(so error code 1001 becomes -991001) to distinguish them from other TS
errors.
A function is provided which will read TS diagnostic output and convert
the TS errors to NG errors if they match this negative error code
format.
PR Close#25647
In tsc 3.0 the check that enables program structure reuse in tryReuseStructureFromOldProgram has changed
and now uses identity comparison on arrays within CompilerOptions. Since we recreate the options
on each incremental compilation, we now fail this check.
After this change the default set of options is reused in between incremental compilations, but we still
allow options to be overriden if needed.
PR Close#25275
This fixes a bug in ngtsc where each @Directive was compiled using a
separate ConstantPool. This resulted in two issues:
* Directive constants were not shared across the file
* Extra statements from directive compilation were dropped instead of
added to the file
This commit fixes both issues and adds a test to verify @Directive is
working properly.
PR Close#25620
This commit adds support for enumeration values. An enumeration value
is now a first-class return value of the resolver, which provides both
a Reference to the enum type itself and the name of the value from that
enum. Resolving an enum itself returns a Map<string, EnumValue>.
PR Close#25619
Ivy definitions in .d.ts files often reference the type of a class.
Sometimes, those classes have generic type parameters. When this is
the case, ngtsc needs to emit generic type parameters in the .d.ts
files (usually by passing 'any').
PR Close#25406
Since non-flat module formats (esm2015, esm5) have different structure
than their flat counterparts (and since we are operating on JS files
inside `node_modules/`, we need to configure TS to include deeply nested
JS files (by specifying a sufficiently high `maxNodeModuleJsDepth`).
Remains to be determined if this has any (noticeable) performance
implications.
PR Close#25406
In some code formats (e.g. ES5) methods can actually be function
expressions. For example:
```js
function MyClass() {}
// this static method is declared as a function expression
MyClass.staticMethod = function() { ... };
```
PR Close#25406
ngtsc's static resolver can evaluate function calls where parameters
have default values. In TypeScript code these default values live on the
function definition, but in ES5 code the default values are represented
by statements in the function body.
A new ReflectionHost method getDefinitionOfFunction() abstracts over
this difference, and allows the static reflector to more accurately
evaluate ES5 code.
PR Close#25406
A small bug caused base factory variable statements for @Component to
not be emitted properly. At the same time as this is fixed, those
statements are now emitted as const.
PR Close#25425
When @angular/core is compiled by ngtsc, a factory file is generated
for ApplicationModule, that is currently invalid because r3_symbols
does not export NgModuleFactory. This change fixes that issue and
ensures the generated ngfactory file for @angular/core is valid.
PR Close#25392
When generating the 'directives:' property of ngComponentDef, ngtsc
needs to be conscious of declaration order. If a directive being
written into the array is declarated after the component currently
being compiled, then the entire directives array needs to be wrapped
in a closure.
This commit fixes ngtsc to pay attention to such ordering issues
within directives arrays.
PR Close#25392
This commit creates an API for factory functions which allows them
to be inherited from one another. To do so, it differentiates between
the factory function as a wrapper for a constructor and the factory
function in ngInjectableDefs which is determined by a default
provider.
The new form is:
factory: (t?) => new (t || SomeType)(inject(Dep1), inject(Dep2))
The 't' parameter allows for constructor inheritance. A subclass with
no declared constructor inherits its constructor from the superclass.
With the 't' parameter, a subclass can call the superclass' factory
function and use it to create an instance of the subclass.
For @Injectables with configured providers, the factory function is
of the form:
factory: (t?) => t ? constructorInject(t) : provider();
where constructorInject(t) creates an instance of 't' using the
naturally declared constructor of the type, and where provider()
creates an instance of the base type using the special declared
provider on @Injectable.
PR Close#25392
Previously, ngtsc used a new ConstantPool for each decorator
compilation. This could result in collisions between constants in the
top-level scope.
Now, ngtsc uses a single ConstantPool for each source file being
compiled, and merges the constant statements into the file after the
import section.
PR Close#25392
The performCompilation() is always called with an undefined oldProgram option (even in watch mode).
This was regression introduced in: 957be960d2
Partial fix, discovered in: #21361
PR Close#21364
Inside of a nested template, an attempt to generate code for a banana-
in-a-box expression would cause a crash in the _AstToIrVisitor, as it
was not handling the case where a write would be generated to a local
variable.
This change supports such a mode of operation.
PR Close#25321
before:
```
Expected to find features 'import * as i0 from "@angular/core";
import { Directive, Input } from '@angular/core';
```
after:
```
Failed to find "template" after "...Component_Factory() { return new
MyComponent(); }," in:
'import * as i0 from "@angular/core";
import { Directive, Input } from '@angular/core';```
```
PR Close#25291
To match the View Engine behavior.
We should make this configurable so that the node injector is tree shaken when
directives do not need to be published.
PR Close#25291
Previously the compiler compliance tests ran and built test code with
real dependencies on @angular/core and @angular/common. This meant that
any changes to the compiler would result in long rebuild processes
for tests to rerun.
This change removes those dependencies and causes test code to be built
against the fake_core stub of @angular/core that the ngtsc tests use.
This change also removes the dependency on @angular/common entirely, as
locality means it's possible to reference *ngIf without needing to link
to an implementation.
PR Close#25248
Existing bootstrap code in the wild depends on the existence of
.ngfactory files, which Ivy does not need. This commit adds the
capability in ngtsc to generate .ngfactory files which bridge
existing bootstrap code with Ivy.
This is an initial step. Remaining work includes complying with
the compiler option to specify a generated file directory, as well
as presumably testing in g3.
PR Close#25176
Before this change bound properties would not be used when matching directives
at runtime.
That is `<ng-template [ngIf]=cond>...</ng-template>` would not trigger the
`ngIf` directive.
PR Close#25272
The optional property on `ts.CompilerHost` is called `realpath` (lower
case), not `realPath` (lower camel case).
It is not clear to me what the impact of this is, but the author's
intent was clearly to override `realpath`.
PR Close#25023
Update XMB placeholders(<ph>) to include the original value on top of an
example. Placeholders can by definition have one example(<ex>) tag and a
text node. The text node is used by TC as the "original" value from the
placeholder, while the example should represent a dummy value.
For example: <ph name="PET"><ex>Gopher</ex>{{ petName }}</ph>.
This change makes sure that we have the original text, but it *DOES NOT*
make sure that the example is correct. The example has the same wrong
behavior of showing the interpolation text rather than a useful
example.
No breaking changes, but tools that depend on the previous behavior and
don't consider the full XMB definition may fail to parse the XMB.
Fixes b/72565847
PR Close#25079