If the compiler CLI is running through closure compiler, the trait
decorator handlers are converted from classes to functions as ES5
is picked as default output target for the bundled version.
The problem is that currently all trait handlers end up having the
same `name`. i.e. an empty string, and therefore adopting previous
traits from a previous build iteration result in the incorrect handler
being used for e.g. registrering, compiling etc- causing
ambiguous/confusing errors down the line in other parts.
We can look into changing the output target in the future, but even
then we are safer using an actual literal due to property renaming.
```$$closure$$NgModuleDecoratorHandler = function() {}`.
It is is questionable if we should just simply NOT run the compiler
through JSCompiler.
PR Close#50673
We have a code path that accesses the `originalKeywordKind` property which logs a deprecation warning in version 5.1, but isn't available in some of the earlier versions that we support. These changes add a compatibility layer that goes through the non-deprecated function, if it exists.
PR Close#50460
Remove convertIndexImportShorthand tsickle option. It's going to be
removed from tsickle in https://github.com/angular/tsickle/pull/1442.
`false` is the default value, so setting it here has no effect
currently.
PR Close#50343
Adds the necessary compiler changes to support input transform functions. The compiler output has changed in the following ways:
### Directive handler
The directive handler now extracts a reference to the input transform function and it resolves the type of its first parameter. It also asserts that the type can be referenced in the compiled output and that it doesn't clash with any pre-existing `ngAcceptInputType_` members.
### .d.ts
In the generated declaration files the compiler now inserts an `ngAcceptInputType_` member for each input with a `transform` function. The member's type corresponds to the type of the first parameter of the function, e.g.
```typescript
// foo.directive.ts
@Directive()
export class Foo {
@Input({transform: (incomingValue: string) => parseInt(incomingValue)}) value: number;
}
// foo.directive.d.ts
export class Foo {
value: number;
static ngAcceptInputType_value: string;
}
```
### Type check block
If an input has `transform` function, the TCB will use the type of its first parameter for the setter type. This uses the same infrastructure as the `ngAcceptInputType_` members.
### Directive declaration
The generated runtime directive declaration call now includes the `transform` function in the `inputs` map, if the input is being transformed. The function will be picked up by the runtime in the next commit to do the actual transformation.
```typescript
// foo.directive.ts
@Directive()
export class Foo {
@Input({transform: (incomingValue: string) => parseInt(incomingValue)}) value: number;
}
// foo.directive.js
export class Foo {
ɵdir = ɵɵdefineDirective({
inputs: {
value: ['value', 'value', incomingValue => parseInt(incomingValue)]
}
});
}
```
PR Close#50225
Adds a new AST for a `TransplantedType` in the compiler which will be used for some upcoming work. A transplanted type is a type node that is defined in one place in the app, but needs to be copied to a different one (e.g. the generated .d.ts). These changes also include updates to the type translator that will rewrite any type references within the type to point to the new context file.
PR Close#50104
This commit adds the `signals: boolean` property to the internal
directive/component metadata. This does not add it to the public API
yet, as the feature has no internal support other than compiler
detection.
PR Close#49981
In this mode the compiler generates code based on each individual source file without using its dependencies. This mode is suitable only for fast edit/refresh during development.
PR Close#49846
NgModules which import standalone components currently list those components
in their injector definitions, because we assume that any standalone
component may export providers from its own imports.
This commit adds an optimization for that emit, which attempts to statically
analyze the NgModule imports and determine which standalone components, if
any are present, do not export providers and thus can be omitted.
This analysis is imperfect, because some imported components may be declared
outside of the current compilation, or transitively import types which are
declared outside the compilation. These types are therefore _assumed_ to
carry providers and so the optimization isn't applied to them.
PR Close#49837
The compiler currently does not check to make sure that directives in
the host bindings are exported. These directives are part of the public
API of the component so they do have to be.
PR Close#49527
Fixes that the compiler was matching directives based on `attr` bindings which doesn't correspond to the runtime behavior. This wasn't a problem until now because the matched directives would basically be a noop, but they can cause issues with required inputs.
PR Close#49713
It seems that changes in prior commits led to a new error in the Windows CI job,
likely due to its sandboxing setup in Bazel. This commit adds an explicit type
annotation that should avoid the error.
PR Close#49136
There used to be a subclass of `TraitCompiler` in ngcc, but now that ngcc has been removed
we can update `TraitCompiler` to no longer expose certain fields and methods.
PR Close#49136
There's an issue where formatting with `clang-format` doesn't agree with itself on how
the docblock for a field named `import` should be indented; if it is indented then it
removes the indentation, but then linting the source file reports an error where it
wants to revert the indentation change. By using computed property syntax this bug
is avoided.
PR Close#49136
The concept of "internal" and "adjacent" type expression used to be necessary to support
ngcc, as it had to process downleveled class declarations using an IIFE, where the class
name within the IIFE could be different from the outer class name. With the removal of
ngcc we no longer need to make this distinction, so this commit removes these concepts
entirely.
PR Close#49136
ngcc's reflection host would recognize tslib helpers and some JS builtin methods to allow
the static interpreter to evaluate compiled and downleveled JS code, but now that ngcc
has been removed this functionality is no longer being used.
PR Close#49136
This commit simplifies various parts of ngtsc to no longer support synthetic decorators,
downleveled enum members and inline declarations. These concepts were present to support
ngcc, but can be dropped now that ngcc has been removed.
PR Close#49136
This diagnostic ensures that the special attribute `ngSkipHydration` is not a binding and has no other value than `"true"` or an empty value.
Fixes#49501
PR Close#49512
When we create a context to inject inside our ngTemplateOutlet, the context was declare as Object, therefore, there are no compilation error.
Now if we add a context, we get error at compile type.
BREAKING CHANGE: If the 'ngTemplateOutletContext' is different from the context, it will result in a compile-time error.
Before the change, the following template was compiling:
```typescript
interface MyContext {
$implicit: string;
}
@Component({
standalone: true,
imports: [NgTemplateOutlet],
selector: 'person',
template: `
<ng-container
*ngTemplateOutlet="
myTemplateRef;
context: { $implicit: 'test', xxx: 'xxx' }
"></ng-container>
`,
})
export class PersonComponent {
myTemplateRef!: TemplateRef<MyContext>;
}
```
However, it does not compile now because the 'xxx' property does not exist in 'MyContext', resulting in the error: 'Type '{ $implicit: string; xxx: string; }' is not assignable to type 'MyContext'.'
The solution is either:
- add the 'xxx' property to 'MyContext' with the correct type or
- add '$any(...)' inside the template to make the error disappear. However, adding '$any(...)' does not correct the error but only preserves the previous behavior of the code.
fix#43510
PR Close#48374
This commit updates parts of the FW to be ES2022 complaint.
These changes are needed to fix the following problems problems with using properties before they are initialized.
Example
```ts
class Foo {
bar = this.buz;
constructor(private buz: unknown){}
}
```
PR Close#49559
This commit updates parts of the FW to be ES2022 complaint.
These changes are needed to fix the following problems problems with using properties before they are initialized.
Example
```ts
class Foo {
bar = this.buz;
constructor(private buz: unknown){}
}
```
PR Close#49332
Adds support for marking a directive input as required. During template type checking, the compiler will verify that all required inputs have been specified and will raise a diagnostic if one or more are missing. Some specifics:
* Inputs are marked as required by passing an object literal with a `required: true` property to the `Input` decorator or into the `inputs` array.
* Required inputs imply that the directive can't work without them. This is why there's a new check that enforces that all required inputs of a host directive are exposed on the host.
* Required input diagnostics are reported through the `OutOfBandDiagnosticRecorder`, rather than generating a new structure in the TCB, because it allows us to provide a better error message.
* Currently required inputs are only supported during AOT compilation, because knowing which bindings are present during JIT can be tricky and may lead to increased bundle sizes.
Fixes#37706.
PR Close#49468
This reverts commit 13dd614cd1.
This breaks a g3 Typescript compilation tests where diagnostics are
expected for a missing input in the component.
PR Close#49467
Adds support for marking a directive input as required. During template type checking, the compiler will verify that all required inputs have been specified and will raise a diagnostic if one or more are missing. Some specifics:
* Inputs are marked as required by passing an object literal with a `required: true` property to the `Input` decorator or into the `inputs` array.
* Required inputs imply that the directive can't work without them. This is why there's a new check that enforces that all required inputs of a host directive are exposed on the host.
* Required input diagnostics are reported through the `OutOfBandDiagnosticRecorder`, rather than generating a new structure in the TCB, because it allows us to provide a better error message.
* Currently required inputs are only supported during AOT compilation, because knowing which bindings are present during JIT can be tricky and may lead to increased bundle sizes.
Fixes#37706.
PR Close#49453
This reverts commit 1a6ca68154.
This breaks tests in google3 which might be depending on private APIs. We
need to update these tests before we can land this PR.
PR Close#49449
Adds support for marking a directive input as required. During template type checking, the compiler will verify that all required inputs have been specified and will raise a diagnostic if one or more are missing. Some specifics:
* Inputs are marked as required by passing an object literal with a `required: true` property to the `Input` decorator or into the `inputs` array.
* Required inputs imply that the directive can't work without them. This is why there's a new check that enforces that all required inputs of a host directive are exposed on the host.
* Required input diagnostics are reported through the `OutOfBandDiagnosticRecorder`, rather than generating a new structure in the TCB, because it allows us to provide a better error message.
* Currently required inputs are only supported during AOT compilation, because knowing which bindings are present during JIT can be tricky and may lead to increased bundle sizes.
Fixes#37706.
PR Close#49304
The decorator downlevel transform is never used for actual class
decorators because Angular class decorators rely on immediate execution
for JIT. Initially we also supported downleveling of class decorators
for View Engine library output, but libraries are shipped using partial
compilation output and are not using this transform anymore.
The transform is exclusively used for JIT processing, commonly for
test files to help ease temporal dead-zone/forward-ref issues. We can
remove the class decorator downlevel logic to remove technical debt.
PR Close#49351
Consider the following scenario:
1. A TS file with a component and templateUrl exists
2. The template file does not exist.
3. First build: ngtsc will properly report the error, via a FatalDiagnosticError
4. The template file is now created
5. Second build: ngtsc still reports the same errror.
ngtsc persists the analysis data of the component and never invalidates
it when the template/style file becomes available later.
This breaks incremental builds and potentially common workflows
where resource files are added later after the TS file is created. This
did surface as an issue in the Angular CLI yet because Webpack requires
users to re-start the process when a new file is added. With ESBuild
this will change and this also breaks incremental builds with
Bazel/Blaze workers.
To fix this, we have a few options:
* Invalidate the analysis when e.g. the template file is missing. Never
caching it means that it will be re-analyzed on every build iteration.
* Add the resource dependency to ngtsc's incremental file graph. ngtsc
will then know via `host.getModifiedResources` when the file becomes
available- and fresh analysis of component would occur.
The first approach is straightforward to implement and was chosen here.
The second approach would allow ngtsc to re-use more of the analysis
when we know that e.g. the template file still not there, but it
increases complexity unnecessarily because there is no **single**
obvious resource path for e.g. a `templateUrl`. The URL is attempted
to be resolved using multiple strategies, such as TS program root dirs,
or there is support for a custom resolution through
`host.resourceNameToFileName`.
It would be possible to determine some candidate paths and add them to
the dependency tracker, but it seems incomplete given possible external
resolvers like `resourceNameToFileName` and also would likely not have
a sufficient-enough impact given that a broken component decorator is
not expected to remain for too long between N incremental build
iterations.
PR Close#49184
Drops support for TypeScript 4.8 from the compiler and removes all of the compatibility code we had for it.
BREAKING CHANGE:
* TypeScript 4.8 is no longer supported.
PR Close#49155
The options to generate NgFactory and NgSummary files were added to Ivy for backwards compatibility with ViewEngine. Since ViewEngine was deprecated and removed, the NgFactory and NgSummary files are no longer used as well.
This commit drops obsolete options to generate NgFactory and NgSummary files. Also, the logic that generates those files is also removed.
PR Close#48268
Uses an alternate approach of preserving default imports that doesn't involve the `getMutableClone` function that is being removed in TypeScript 5.0.
The alternate approach was already used in the downlevel transform and it works by patching the EmitResolver of the current transformation context to tell TypeScript to preserve the import.
PR Close#49070
In #48898 the `isForwardRef` flag was added to indicate whether a reference should be wrapped in a `forwardRef`. This logic assumed that the node can't be referring to another node within the same file, however from testing it looks like that's not actually the case, because we hit the same code path when an external import to the same symbol exists already.
PR Close#48988
In the `PotentialImport` we indicate if it's in the same file by not setting a `moduleSpecifier`, but if that's the case, the imported symbol might need to be wrapped in a `forwardRef` to avoid generating an error. These changes expose this information so the various tools can take advantage of it.
PR Close#48898
Some 1p module which uses the method TscPlugin.wrapHost requires to import this type to make its internal class definitions compatible with this type.
PR Close#48874
This commit updates one usage of the `ts.factory.createMethodDeclaration` API
to avoid a deprecated function signature, which avoids logging a warning.
PR Close#48812
Reworks some of the existing compiler APIs to make them easier to use in a schematic and exposes a few new ones to surface information we already had. High-level list of changes:
* `getPotentialImportsFor` now requires a class reference, instead of a `PotentialDirective | PotentialPipe`.
* New `getNgModuleMetadata` method has been added to the type checker.
* New `getPipeMetadata` method has been added to the type checker.
* New `getUsedDirectives` method has been added to the type checker.
* New `getUsedPipes` method has been added to the type checker.
* The `decorator` property was exposed on the `TypeCheckableDirectiveMeta`. The property was already present at runtime, but it wasn't specified on the interface.
PR Close#48730
NgModules can re-export other NgModules, which transitively includes all traits exported by the re-exported NgModule. We want to be able to suggest *all* re-exports of a component when trying to auto-import it.
Previously, we used an approximation when importing from NgModules: we looked at a Component's metadata, and just imported the declaring NgModule. However, this is not technically correct -- the declaring NgModule it is not necessarily the same one that exports it for the current scope. (Indeed, there could be multiple re-exports!) As a replacement, I have implemented a more general solution.
This PR introduces a new class on the template type checker, called `NgModuleIndex`. When queried, it conducts a depth-first-search over the NgModule import/export graph, in order to find all NgModules anywhere in the current dependency graph, as well as all exports of those NgModules. This allows the language service to suggest all of the re-exports, in addition to the original export.
PR Close#48354
`MetadataReaderWithIndex.getKnown` currently returns an iterator. It will be easier to work with for upcoming usages if it returns an array instead.
PR Close#48354
Fixes a deprecation warning that was being logged by compiler when generating aliases, because we weren't going through `ts.factory` to create an AST node.
PR Close#48652
In #47167 an `updateClassDeclaration` call was swapped out with a `createClassDeclaration` which caused a regression where interface references were being retained when using a custom decorator in a project that has `emitDecoratorMetadata` enabled.
These changes switch back to use `updateClassDeclaration`.
Fixes#48448.
PR Close#48638
We dropped support for TypeScript 4.7 in version 15, but we had to keep around the runtime code, because of g3. Now that g3 is on 4.8, we can remove the additional code.
PR Close#48470
Since we generate a `.mjs` file as entry-point for jasmine tests,
a couple of issues prevented the transitive dependencies from
bootstrap targets to be brought in (causing resolution errors):
1. The `_files` (previously `_esm2015`) targets are no longer needed,
and they also miss all the information on runfiles.
2. The aspect for computing linker mappings does not respect the
`bootstrap` attribute from the `spec_entrypoint` so we manually
add the extract ESM output targets (this rule works with the aspect
and forwards linker mappings).
PR Close#48521
For every `ts_library` target we expose a shorthand that grants
access to the JS files because `DefaultInfo` of a ts library
only exposes the `.d.ts` files.
We rename this away from `es2015` since in practice it's a much
higher target these days. Additionally we no longer use the devmode
output but rather use the prodmode output which has the explicit
`.mjs` output- compatible with ESM.
PR Close#48521
The `__ESM_IMPORT_META_URL__` trick was used because we used both ESM
and CommonJS in this repo. It was an interop needed because
`import.meta.url` syntax couldn't be used as it woud have caused syntax
errors.
We still need to keep the CommonJS/ESM interop in the compiler-cli
because g3 relies on the compiler and uses CommonJS. This affects very
few places, just in the compiler- so this is acceptable.
PR Close#48521
For standalone components it may be beneficial to group multiple declarations
into a single array, that can then be imported all at once in `Component.imports`.
If this array is declared within a library, however, would the AOT compiler
need to extract the contents of the array from the declaration file. This
requires that the array is constructed using an `as const` cast, which results
in a readonly tuple declaration in the generated .d.ts file of the library:
```ts
export declare const DECLARATIONS: readonly [typeof StandaloneDir];
```
The partial evaluator logic did not support this syntax, so this pattern was
not functional when a library is involved. This commit adds the necessary
logic in the static interpreter to evaluate this type at compile time.
Closes#48089
PR Close#48091
Because the language service uses the compiler, we try to produce as
much useful information as possible rather than throwing hard errors.
Hard errors cause the compiler to crash. While this can be acceptable
when compiling a program as part of a regular build, this is undesirable
for the language service.
PR Close#48314
The stricter checks under `strictInjectionParameters` in Angular 15 now enforce that
an inherited constructor must be compatible with DI, based on whether all parameters
are valid injection tokens. There is an issue when the constructor is inherited from
a class in a declaration file though, as information on the usage of `@Inject()` is
not present within a declaration file. This means that this stricter check cannot be
accurately performed, resulting in false positives.
This commit disables the stricter check to behave the same as it did prior to
Angular 15, therefore avoiding the false positive.
Fixes#48152
PR Close#48156
`getPotentialPipes` returns possible pipes which can be used in the provided context, whether already in scope or requiring an import.
This is necessary to implement auto-import support for pipes in the language service.
PR Close#48090
Currently, when generating an import of a selector, the language service might crash if the compiler cannot emit a reference to the new symbol's file from the target component's file. (This might happen because the two are the same file.) We should handle that case by reusing the existing import if possible, or otherwise failing gracefully.
PR Close#47938
Currently `ngc-wrapped` mostly relies on any casts/or disabled
strictness checks to be able to use `tsickle`'s emit callback and
emit result merging for ngtsc. We should change this so that supertypes
of `ts.EmitResult` can be used in these optional callbacks- allowing us
to enable strictness checks in `packages/bazel/...` too.
PR Close#47893
Implements more of the runtime validations for host directives as compiler diagnostics so that they can be caught earlier. Also does some minor cleanup.
PR Close#47768
The supported Node.js versions for the `@angular/compiler-cli` package (^14.15.0 || >=16.10.0)
allow for the use of the `recursive` option of `mkdirSync`. Using the `recursive` option
removes the need to manually create each subdirectory in a given path.
PR Close#47678
In AOT compilations, the `strictInjectionParameters` compiler option can
be enabled to report errors when an `@Injectable` annotated class has a
constructor with parameters that do not provide an injection token, e.g.
only a primitive type or interface.
Since Ivy it's become required that any class with Angular behavior
(e.g. the `ngOnDestroy` lifecycle hook) is decorated using an Angular
decorator, which meant that `@Injectable()` may need to have been added
to abstract base classes. Doing so would then report an error if
`strictInjectionParameters` is enabled, if the abstract class has an
incompatible constructor for DI purposes. This may be fine though, as
a subclass may call the constructor explicitly without relying on
Angular's DI mechanism.
Therefore, this commit excludes abstract classes from the
`strictInjectionParameters` check. This avoids an error from being
reported at compile time. If the constructor ends up being used by
Angular's DI system at runtime, then the factory function of the
abstract class will throw an error by means of the `ɵɵinvalidFactory`
instruction.
In addition to the runtime error, this commit also analyzes the inheritance
chain of an injectable without a constructor to verify that their inherited
constructor is valid.
BREAKING CHANGE: Invalid constructors for DI may now report compilation errors
When a class inherits its constructor from a base class, the compiler may now
report an error when that constructor cannot be used for DI purposes. This may
either be because the base class is missing an Angular decorator such as
`@Injectable()` or `@Directive()`, or because the constructor contains parameters
which do not have an associated token (such as primitive types like `string`).
These situations used to behave unexpectedly at runtime, where the class may be
constructed without any of its constructor parameters, so this is now reported
as an error during compilation.
Any new errors that may be reported because of this change can be resolved either
by decorating the base class from which the constructor is inherited, or by adding
an explicit constructor to the class for which the error is reported.
Closes#37914
PR Close#44615
Updates the version range in the compiler to require at least TypeScript 4.8. Note that I'm keeping the backwards-compatibility layer for 4.7 around for now until internal projects have been migrated to 4.8.
BREAKING CHANGE:
TypeScript versions older than 4.8 are no longer supported.
PR Close#47690
Previously when a file was being analyzed to determine if a shim should
be generated, up to two calls to the host `fileExists` function per file
per generator were made. In the default host, each `fileExists` call made
two underlying file system calls. Following these calls, the file was then
read via `getSourceFile`. However, `getSourceFile` will return `undefined`
if the requested file does not exist. As a result, `getSourceFile` can be
used directly to request both potential file names and leverage the return
value to determine if the file does not exist. This avoids the need to call
`fileExists` at all.
PR Close#47682
`getPotentialImportsFor` returns an array of possible imports, including TypeScript module specifier and identifier name, for a requested trait in the context of a given component.
PR Close#47631
The previous commit 2e1dddec45 used `@ts-expect-error` to suppress the
current error, with the intent of being informed once that's no longer
an error, ie. when we updated to an upstream TS version that includes
this change.
However this unfortunately means the change is incompatible with the
fixed version, which prevents it from working with an updated TS version
in google3.
This change reverts back to the original `@ts-ignore` which is forwards
and backwards compatible, avoiding that problem (but unfortunately
losing the benefit of being notified once fixed).
PR Close#47636
`getPotentialTemplateDirectives` returns possible directives which can be used in the provided context, whether already in scope or requiring an import.
This is necessary to implement auto-import support for standalone components in the language service.
PR Close#47561
After implementing `getPotentialTemplateDirectives`, we will use this data struture to represent both in-scope and out-of-scope directives. So this rename is an advance cleanup.
PR Close#47561
The latest TypeScript compiler exposes the previously private field
`hasInvalidatedResolutions`. That breaks Angular in the newer TS,
because the new field would be required on DelegatingCompilerHost.
However we cannot just add the field here, because it's not present in
the older compiler.
This change adds the field for delegation, which works at runtime
because the field is present. It suppresses the compiler error using a
`// @ts-expect-error`, which should be removed once Angular moves to a
TSC version that includes this change.
PR Close#47585
When reporting type-checking diagnostics in external templates we create a
`ts.SourceFile` of the template text, as this is needed to report Angular
template diagnostics using TypeScript's diagnostics infrastructure. Each
reported diagnostic would create its own `ts.SourceFile`, resulting in
repeatedly parsing of the template text and potentially high memory usage
if the template is large and there are many diagnostics reported. This commit
caches the parsed template in the template mapping, such that all reported
diagnostics get to reuse the same `ts.SourceFile`.
Closes#47470
PR Close#47471
This commit adds a re-export of the `NgForOf` class as `NgFor` to improve the DX for cases when the directive is used as standalone. Developers can import `NgFor` class, which better matches the `ngFor` attribute used in a template.
PR Close#47309
Using raw objects as a lookup structure will inadvertently find methods defined on
`Object`, where strings are expected. This causes errors downstream when string
operations are applied on functions.
This commit switches over to use `Map`s in the DOM element schema registry to fix
this category of issues.
Fixes#46936
PR Close#47220
When the Angular compiler emits a diagnostic in a template file, it
forces TypeScript to parse that template. Templates are not TypeScript,
so this parse finds a bunch of parsing errors, which Angular then
ignores and we show the diagnostic anyways because we have more context.
This can lead to strange behavior in TypeScript because templates are so
weird that it can break the parser and crash the whole compiler.
For example, certain Angular templates can encounter failures fixed by
microsoft/TypeScript#45987, which are not easily debuggable and require
a TS upgrade to fix.
This commit introduces logic to handle the error gracefully, by falling
back to report the template error on the component class itself. The
diagnostic is extended to still reference the template location and
includes the failure's stack trace, to allow the parsing failure to be
reported to TypeScript (as parsing should in theory not cause a crash).
Closes#43970
PR Close#44001
This option has no longer any effect as Ivy is the only rendering engine.
BREAKING CHANGE: Angular compiler option `enableIvy` has been removed as Ivy is the only rendering engine.
PR Close#47346
This is the compile-time implementation of the `hostDirectives` feature plus a little bit of runtime code to illustrate how the newly-generated code will plug into the runtime. It works by creating a call to the new `ɵɵHostDirectivesFeature` feature whenever a directive has a `hostDirectives` field. Afterwards `ɵɵHostDirectivesFeature` will patch a new function onto the directive definition that will be invoked during directive matching.
For example, if we take the following definition:
```ts
@Directive({
hostDirectives: [HostA, {directive: HostB, inputs: ['input: alias']}]
})
class MyDir {}
```
Will compile to:
```js
MyDir.ɵdir = ɵɵdefineComponent({
features: [ɵɵHostDirectivesFeature([HostA, {
directive: HostB,
inputs: {
input: "alias"
}
}])]
});
```
The template type checking is implemented during directive matching by adding the host directives applied on the host to the array of matched directives whenever the host is matched in a template.
Relates to #8785.
PR Close#46868
This helper accepts a class for an Angular trait, and returns the NgModule which owns that trait. This will be useful for the language service import project, which needs to edit import arrays on the module.
PR Close#47166
Replaces (almost) all of the usages of the deprecated `getMutableClone` function from TypeScript which has started to log deprecation warnings in version 4.8 and will likely be removed in version 5.0. The one place we have left is in the default import handling of ngtsc which will be more difficult to remove.
PR Close#47167
This helper accepts a class, and returns the primary Angular Decorator associated with that trait (e.g. the Component, Pipe, Directive, or NgModule decorator). This will be useful for the language service import project, which needs to edit import arrays inside the decorator.
PR Close#47180
Adds support for TypeScript 4.8 and resolves some issues that came up as a result of the update.
Most of the issues came from some changes in TypeScript where the `decorators` and `modifiers` properties were removed from most node types, and were combined into a single `modifiers` array. Since we need to continue supporting TS 4.6 and 4.7 until v15, I ended up creating a new `ngtsc/ts_compatibility` directory to make it easier to reuse the new backwards-compatible code.
PR Close#47038
Updates the tsickle version in the repository and accounts for its changes in
the `compiler-cli` package. Tsickle made a breaking change in the minor version
segment bump that would break the use with `@angular/compiler-cli`
Additionally the tsickle version for `@angular/bazel` is updated since
we updated `@bazel/typescript` to also account for the breaking changes.
See: 78a0528107
PR Close#47018
The diagnostic of the component missing member comes from the ts service,
so the all code fixes for it are delegated to the ts service.
The code fixes are placed in the LS package because only LS can benefit from
it now, and The LS knows how to provide code fixes by the diagnostic and NgCompiler.
The class `CodeFixes` is useful to extend the code fixes if LS needs to
provide more code fixes for the template in the future. The ts service uses
the same way to provide code fixes.
1622247636/src/services/codeFixProvider.ts (L22)
Fixes https://github.com/angular/vscode-ng-language-service/issues/1610
PR Close#46764
improve the error message for non-standalone components which are not
exported from their module, and that are also imported directly as if
they were standalone
this change simply adds the suggestion to the developer to import the
ngModule instead
resolves#46004
PR Close#46114
The extended diagnostics about missing control flow directive was only mentioning that the `CommonModule` should be imported.
Now that the control flow directives are available as standalone, the message mentions that directive itself can be imported.
The message now also mentions which import should be used for the directive (as it can be tricky to figure out that `NgForOf` is the directive corresponding to `*ngFor`).
PR Close#46846
After a bugfix in #46096, the compiler is now better capable of detecting pipes
which require an inline type constructor. However, there is an issue in how all
pipes are considered when verifying the inline type-ctor requirement: it should
only check actually used pipes.
Fixes#46747
PR Close#46807
This commit adds an extended diagnostics check that is similar to the nullish
coalescing check, but targeting optional chains. If the receiver expression
of the optional chain is non-nullable, then the extended diagnostic can report
an error or warning that can be fixed by changing the optional chain into a
regular access.
Closes#44870
PR Close#46686
This commit adds an extended diagnostic which warns when style suffixes such as '.px'
are used with attribute bindings (attr.width.px).
Fixes#36256
PR Close#46651
In the case that a user accidentally forgot the let keyword, they dont get a very clear indicator of there being a problem.
They get an issue in the template iteration at runtime. This diagnostic will warn the user when the let keyword is missing.
PR Close#46683
https://angular.io/guide/attribute-binding#attribute-class-and-style-bindings
Angular supports `attr.`, `style.`, and `class.` binding prefixes to
bind attributes, styles, and classes. If the key does not have the
binding syntax `[]` or the value does not have an interpolation `{{}}`,
the attribute will not be interpreted as a binding.
This diagnostic warns the user when the attributes listed above will not
be interpreted as bindings.
resolves#46137
PR Close#46161
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
This commit adds an extended diagnostics check that verifies that all control flow directives (such as `ngIf`, `ngFor`) have the necessary directives imported in standalone components. Currently there is no diagnostics produced for such cases, which makes it harder to detect and find problems.
PR Close#46146
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
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
When generating .d.ts metadata for NgModules, by default we emit type
references to their declarations, imports, and exports. However, this
information is not necessarily useful to consumers. References to private
directives (those that aren't exported by the NgModule) for example aren't
at all useful as they can only affect other components declared in the
NgModule. References to imports are of limited usefulness - they might be
helpful for an IDE to understand the DI structure of an application, but
aren't at all used by a downstream compiler.
Generating this metadata is not without cost. When an incremental build
system uses changes in inputs to determine when a rebuild is necessary, any
changes in .d.ts files might cause downstream targets to rebuild. If those
.d.ts changes are in the "private" side of the NgModule (imports or non-
exported directives/pipes), then these rebuilds are wholly unnecessary.
This commit introduces the `onlyPublishPublicTypingsForNgModules` flag for
the compiler. When this flag is set, the compiler will filter the emitted
references in NgModule .d.ts output and only reference those directives/
pipes that are exported from the NgModule (its public API surface). Omitting
the flag preserves the existing behavior of emitting all references, both
public and private.
This is especially useful for build systems such as Bazel.
PR Close#45894
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
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
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
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
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
This commit improves the error message for using `imports` on a component
that isn't set to `standalone: true`. Two concrete improvements are made:
* A related information message is added to the diagnostic which suggests
the fix of adding `standalone: true`.
* The component is marked as poisoned, preventing other errors which might
be caused by an incorrectly configured template scope from being generated
and thus masking the original problem.
Fixes#45850
PR Close#45851
In AOT compilations, the `strictInjectionParameters` compiler option can
be enabled to report errors when an `@Injectable` annotated class has a
constructor with parameters that do not provide an injection token, e.g.
only a primitive type or interface.
Since Ivy it's become required that any class with Angular behavior
(e.g. the `ngOnDestroy` lifecycle hook) is decorated using an Angular
decorator, which meant that `@Injectable()` may need to have been added
to abstract base classes. Doing so would then report an error if
`strictInjectionParameters` is enabled, if the abstract class has an
incompatible constructor for DI purposes. This may be fine though, as
a subclass may call the constructor explicitly without relying on
Angular's DI mechanism.
Therefore, this commit excludes abstract classes from the
`strictInjectionParameters` check. This avoids an error from being
reported at compile time. If the constructor ends up being used by
Angular's DI system at runtime, then the factory function of the
abstract class will throw an error by means of the `ɵɵinvalidFactory`
instruction.
In addition to the runtime error, this commit also analyzes the inheritance
chain of an injectable without a constructor to verify that their inherited
constructor is valid.
Closes#37914
PR Close#44615
Excludes styles that resolve to empty strings from the emitted metadata so that they don't result in empty `<style>` tags at runtime.
Fixes#31191.
PR Close#45459
Changes the message from:
```
The component 'HelloComponent' appears in 'imports', but is not standalone
and cannot be imported directly It must be imported via an NgModule.
```
to
```
The component 'HelloComponent' appears in 'imports', but is not standalone
and cannot be imported directly. It must be imported via an NgModule.
```
PR Close#45827
The analysis phase of the compiler should operate on individual classes, independently
of the analysis of other classes. The validation that `Component.imports` only
contains standalone entities or NgModules however did happen during the analysis phase,
introducing a dependency on other classes and causing inconsistencies due to ordering
and/or asynchronous timing differences.
This commit fixes the issue by moving the validation to the resolve phase, which occurs
after all classes have been analyzed.
Fixes#45819
PR Close#45827
This commit updates the logic to detect a situation when a standalone component is used in the NgModule-based bootstrap (`@NgModule.bootstrap`). Both AOT and JIT compilers are updated to handle this situation.
PR Close#45825
Adds support for TypeScript 4.7. Changes include:
* Bumping the TS version as well as some Bazel dependencies to include https://github.com/bazelbuild/rules_nodejs/pull/3420.
* Adding a backwards-compatibility layer for calls to `updateTypeParameterDeclaration`.
* Making `LView` generic in order to make it easier to type the context based on the usage. Currently the context can be 4 different types which coupled with stricter type checking would required a lot of extra casting all over `core`.
* Fixing a bunch of miscellaneous type errors.
* Removing assertions of `ReferenceEntry.isDefinition` in a few of the language service tests. The field isn't returned by TS anymore and we weren't using it for anything.
* Resolving in error in the language service that was caused by TS attempting to parse HTML files when we try to open them. Previous TS was silently setting them as `ScriptKind.Unknown` and ignoring the errors, but now it throws. I've worked around it by setting them as `ScriptKind.JSX`.
PR Close#45749
Before standalone, everything that could appear in an NgModule's `imports`
was relevant to DI, and needed to be emitted in the `imports` of the
generated `InjectorDef` definition. With the introduction of standalone
types, NgModule `imports` can now contain components, directives, and pipes
which are standalone. Only standalone components need to be included in
the `imports` of the generated injector definition - directives and pipes
have no effect on DI. Having them present doesn't cause any errors in the
runtime (they're filtered out by the injector itself) but it does prevent
tree-shaking.
With this commit, the generation of `InjectorDef` now filters the `imports`
to exclude directives and pipes as much as possible. It's not _always_
possible because an expression in `imports` may pull in both a directive and
a `ModuleWithProviders` reference, and we have no way of referencing just
the MWP part of that expression. Therefore this is an optimization, not a
rule of `InjectorDef` compilation.
PR Close#45701
Previously, the NgModule handler would resolve the `imports` field as one
unit, producing an array of `Reference`s. With this refactoring, if
`imports` is a literal array, each individual element will be resolved
independently. This will allow filtering in the future at the element level,
since there will be a separate `ts.Expression` for each individual element.
PR Close#45701
This commit updates the `ForeignFunctionResolver` used by the NgModule
handler to resolve `ModuleWithProvider` types. Previously, this resolver
returned the NgModule `Reference` directly, but there are two problems with
this:
* It's not completely accurate, as the expression returned by the MWP call
will not return the NgModule at runtime.
* We need the ability to distinguish the MWP call itself from an ordinary
NgModule reference in future optimizations.
PR Close#45701
This commit reworks the partial evaluation system's concept of a
ForeignFunctionResolver. Previously, resolvers were expected to return a
`ts.Expression` which the partial evaluator would continue evaluating,
eventually returning a value.
This works well for "transparent" foreign functions like `forwardRef`,
but for things like `ModuleWithProviders` it breaks down, because the
desired resolution value (the NgModule `Reference`) is _not_ the "correct"
evaluation of the function call.
To support better FFR implementations, this commit refactors the FFR system
so that resolvers operate on the `ts.CallExpression` instead, and are
given a callback to resolve further expressions if needed. If they cannot
resolve a given call expression, they have an `unresolvable` value that they
can return to indicate that.
PR Close#45701
This commit adds a type field to .d.ts metadata for directives, components,
and pipes which carries a boolean literal indicating whether the given type
is standalone or not. For backwards compatibility, this flag defaults to
`false`.
Tests are added to validate that standalone types coming from .d.ts files
can be correctly imported into new standalone components.
PR Close#45672
Standalone component scopes were first implemented in the
`ComponentDecoratorHandler` itself, due to an assumption that "standalone"
allowed for a localized analysis of the component's dependencies. However,
this is not strictly true. Other compiler machinery also needs to understand
component scopes, including standalone component scopes. A good example is
the template type-checking engine, which uses a `ComponentScopeReader` to
build full metadata objects (that is, metadata that considers the entire
inheritance chain) for type-checking purposes. Therefore, the
`ComponentScopeReader` should be able to give the scope for a standalone
component.
To achieve this, a new `StandaloneComponentScopeReader` is implemented, and
the return type of `ComponentScopeReader.getScopeForComponent` is expanded
to express standalone scopes. This cleanly integrates the "standalone"
concept into the existing machinery.
PR Close#45672
This commit expands on the unified dependency tracking in the previous
commit and adds tracking of NgModule dependencies. These are not used for
standard components, but are emitted for standalone components to allow the
runtime to roll up providers from those NgModules into standalone injectors.
PR Close#45672
Previously, the compiler tracked directives and pipes in template scopes
separately. This commit refactors the scope system to unify them into a
single data structure, disambiguated by a `kind` field.
PR Close#45672
Previously, the compiler would represent template dependencies of a
component in its component definition through separate fields (`directives`,
`pipes`).
This commit refactors the compiler/runtime interface to use a single field
(`dependencies`). The runtime component definition object still has separate
`directiveDefs` and `pipeDefs`, which are calculated from the `dependencies`
when the definition is evaluated.
This change is also reflected in partially compiled declarations. To ensure
compatibility with partially compiled code already on NPM, the linker
will still honor the old form of declaration (with separate fields).
PR Close#45672
`PipeSymbol` contains logic to detect changes in the public API surface of
pipes, which includes the pipe name. However, the pipe handler inadvertently
uses the pipe class name instead of the actual pipe name to initialize the
`PipeSymbol`, which breaks incremental compilation when pipe names change.
There is a test which attempts to verify that this logic is working, but the
test actually passes for a different reason. The test swaps the names of 2
pipes that are both used in a component, and asserts that the component is
re-emitted, theoretically because the public APIs of the pipes is changed.
However, the emit order of the references to the pipes depends on the order
in which they match in the template, which changes when the names are
swapped. This ordering dependency is picked up by the semantic dependency
tracking system, and is what actually causes the component to be re-emitted
and therefore the pipe test to pass in spite of the bug with name tracking.
This commit fixes the `PipeSymbol` initialization to use the correct pipe
name. The test is still flawed in that it's sensitive to the ordering of
pipe emits, but this ordering is due to change soon as a result of the
standalone components work, so this issue will be resolved in a future
commit.
PR Close#45672
This commit adds a new internal scope to `R3Injector` for
`EnvironmentInjector`s specifically. This will allow us to scope services to
the environment side of the injector hierarchy specifically, as opposed to
the `'any'` scope which also includes view-side injectors created via
`Injector.create`. For now, this functionality is not exposed publicly, but
is available to use within `@angular/core` only.
PR Close#45626
This commit fixes an inconsistency where a type check location for an inline
type check block would be interpreted to occur in a type-checking shim instead.
This resulted in a missing template mapping, causing a crash due to an unsafe
non-null assertion operator.
In the prior commit the `TcbLocation` has been extended with an `isShimFile`
field that is now being used to look for the template mapping in the correct
location. Additionally, the non-null assertion operator is refactored such
that a missing template mapping will now ignore the warning instead of crashing
the compiler.
Fixes#45413
PR Close#45454
Extends `TcbPosition` with a field that indicates whether the `tcbPath` is a
type-checking shim file, or an original source file with an inline type check
block.
This field is used in an upcoming commit that fixes an inconsistency with how
inline type check blocks are incorrectly interpreted as a type-checking shim
file instead.
PR Close#45454
Inline type check blocks (TCBs) are emitted into the original source file, but
node positions would still be represented as a `ShimLocation` with a `shimPath`
corresponding with the type-checking shim file. This results in inconsistencies,
as the `positionInShimFile` field of `ShimLocation` would not correspond with
the `shimPath` of that `ShimLocation`.
This commit is a precursor to letting `ShimLocation` also represent the correct
location for inline type check blocks, by renaming the interface to
`TcbLocation`. A followup commit addresses the actual inconsistency.
PR Close#45454
This commit implements the next step of Angular's "standalone" functionality,
by allowing directives/components/pipes declared as `standalone` to be imported
into NgModules. Errors are raised when such a type is not standalone but is
included in an NgModule's imports.
PR Close#44973
This commit moves the error for declaring a standalone directive/component/
pipe to the `LocalModuleScopeRegistry`. Previously the error was produced
by the `NgModuleHandler` directly.
Producing the error in the scope registry allows the scope to be marked as
poisoned when the error occurs, preventing spurious downstream errors from
surfacing.
PR Close#44973
This commit improves the error messages generated by the compiler when NgModule
scope analysis finds structural issues within a compilation. In particular,
errors are now shown on a node within the metadata of the NgModule which
produced the error, as opposed to the node of the erroneous declaration/import/
export. For example, if an NgModule declares `declarations: [FooCmp]` and
`FooCmp` is not annotated as a directive, component, or pipe, the error is now
shown on the reference to `FooCmp` in the `declarations` array expression.
Previously, the error would have been shown on `FooCmp` itself, with a mention
in the error text of the NgModule name.
Additional error context in some cases has been moved to related information
attached to the diagnostic, which further improves the legibility of such
errors. Error text has also been adjusted to be more succinct, since more info
about the error is now delivered through context.
PR Close#44973
Before the `SemanticSymbol` system which now powers incremental compilation,
the compiler previously needed to track which NgModules contributed to the
scope of a component in order to recompile correctly if something changed.
This commit removes that legacy field (which had no consumers) as well as the
logic to populate it.
PR Close#44973
As mentioned in previous commits (check them for more details), `@bazel/typescript`
no longer contains `ts_library`-specific code, so we no longer need that dependency.
PR Close#45431
.substr() is deprecated so we replace it with functions which work similarily but aren't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
PR Close#45397
Drops support for TypeScript older than 4.6 and removes some workarounds in the compiler.
BREAKING CHANGE:
TypeScript versions older than 4.6 are no longer supported.
PR Close#45394
In early versions of Angular, it was sometimes necessary to provide a
`moduleId` to `@Component` metadata, and the common pattern for doing this
was to set `moduleId: module.id`. This relied on the bundler to fill in a
value for `module.id`.
However, due to the superficial similarity between `Component.moduleId` and
`NgModule.id`, many users ended up setting `id: module.id` in their
NgModules. This is an anti-pattern that has a few negative effects,
including preventing the NgModule from tree-shaking properly.
This commit changes the compiler to ignore `id: module.id` in NgModules, and
instead provide a warning which suggests removing the line entirely.
PR Close#45024
Previously, the `TraitCompiler` would naively consider a compilation as
failed if either analysis or resolution produced any diagnostics. This
commit adjusts the logic to only consider error diagnostics, which allows
warnings to be produced from `DecoratorHandler`s.
This is a precursor commit to introducing such a warning. As such, the
logic here will be tested in the next commit.
PR Close#45024
Angular contains an NgModule registry, which allows a user to declare
NgModules with string ids and retrieve them via those ids, using the
`getNgModuleById` API.
Previously, we attempted to structure this registration in a clever fashion
to allow for tree-shaking of registered NgModules (that is, those with ids).
This sort of worked due to the accidental alignment of behaviors from the
different tree-shakers involved. However, this trick relies on the
generation of `.ngfactory` files and how they're specifically processed in
various bundling scenarios. We intend to remove `.ngfactory` files, hence
we can no longer rely on them in this way.
The correct solution here is to recognize that `@NgModule({id})` is
inherently declaring a global side-effect, and such classes should not
really be eligible for tree-shaking in the first place. This commit removes
all the old registration machinery, and standardizes on generating a side-
effectful call to `registerNgModuleType` for NgModules that have ids.
There is some risk here that NgModules with unnecessary `id`s may not
tree-shake as a result of this change, whereas they would have in previous
circumstances. The fix here should be to remove the `id` if it's not needed.
Specifying an `id` is a request that the NgModule be retained regardless of
any other references, in case it is later looked up by string id.
PR Close#45024
The `compileNgModule` operation previously supported a flag `emitInline`,
which controlled whether template scoping information for the NgModule was
emitted directly into the compiled NgModule definition, or whether an
associated statement was generated which patched the information onto the
NgModule definition. Both options are useful in different contexts.
This commit changes this flag to an enum (and renames it), which allows for
a third option - do not emit any template scoping information. This option
is added to better represent the actual behavior of the Angular Linker,
which sometimes configures `compileNgModule` to use the side-effectful
statement generation but which does not actually emit such associated
statements. In other words, the linker effectively does not generate
scoping information for NgModules at all (in some configurations) and this
option more directly expresses that behavior.
This is a refactoring as no generated code is changed as a result of
introducing this flag, due to the linker's behavior of not emitting
associated statements.
PR Close#45024
When parsing interpolations, the input string is _decoded_ from what was
in the orginal template. This means that we cannot soley rely on the input
string to compute source spans because it does not necessarily reflect
the exact content of the original template. Specifically, when there is
an HTML entity (i.e. ` `), this will show up in its decoded form
when processing the interpolation (' '). We need to compute offsets
using the original _encoded_ string.
Note that this problem only surfaces in the splitting of interpolations.
The spans to this point have already been tracked accurately. For
example, given the template ` <div></div>`, the source span for the
`div` is already correctly determined to be 6. Only when we encounter
interpolations with many parts do we run into situations where we need
to compute new spans for the individual parts of the interpolation.
PR Close#44811
Proactively replaces our usages of the deprecated `ts.create*` methods in favor of using `ts.factory.create*` so that we're not surprised when the TS removes them in the future. Also accounts for some cases where the signature had changed.
PR Close#45134
Before this, the compiler resolves the value in the DTS as dynamic.
If the `trigger` is imported from `@angular/animations`, this PR will
use FFR to simulate the actual implementation in JS and extracts the
animation name.
PR Close#45107
This commit implements the first phase of standalone components in the Angular
compiler. This mainly includes the scoping rules for standalone components
(`@Component({imports})`).
Significant functionality from the design is _not_ implemented by this PR,
including:
* imports of standalone components into NgModules.
* the provider aspect of standalone components
Future commits will address these issues, as we proceed with the design of
this feature.
PR Close#44812
In preparation for standalone components, this commit moves the logic which
determines the potential set of components/directives/pipes in a template into
a separate function. This is a simple but crucial refactoring that breaks the
assumption that all template scopes come from NgModules.
PR Close#44812
Previously each `DecoratorHandler` in the compiler was stored in a single file
in the 'annotations' package. The `ComponentDecoratorHandler` in particular was
several thousand lines long.
Prior to implementing the new standalone functionality for components, this
commit refactors 'annotations' to split these large files into their own build
targets with multiple separate files. This should make the implementation of
standalone significantly cleaner.
PR Close#44812
The logical filesystem would store a cached result based on the canonical path,
where the cached value contains the physical path that was originally provided.
This meant that other physical paths with an identical canonical path would use
a cached result derived from another physical path.
This inconsistency is not known to result in actual issues but is primarily
being made as a performance improvement, as using the provided physical paths
as cache key avoids the need to canonicalize the path if its result is already
cached.
PR Close#44798
The generated imports should normally use module specifiers that are valid for
use in production code, where arbitrary relative imports into e.g. node_modules
are not allowed. For template type-checking code it is however acceptable to
use relative imports, as such files are never emitted to JS code. It is
desirable to allow a filesystem relative import as fallback if an import would
otherwise fail to be generated, as doing so allows fewer situations from
needing an inline type constructor.
PR Close#44798
This commit removes the leftover `Identifiers` class that was used in the
ViewEngine compiler. The remaining usages of the `inlineInterpolate` and
`interpolate` instructions were refactored to make use of an
`InterpolationExpression` output expression to capture the argument list of an
interpolation expression. An attempt was made to refactor this further by
converting to the desired interpolation instruction immediately, but some
downstream consumers are designed in a way where the argument list itself is
needed, e.g. as other arguments need to be prepended/appended.
PR Close#44676
So-called "Quote expressions" were added in b6ec2387b3
to support foreign syntax to be used in Angular templates, requiring a custom
template transform to convert them somehow during compilation. Support for template
transforms was originally implemented in a43ed79ee7 but
has since been dropped. Since the compiler is not public API the quote expressions
should not have any usages anymore. Removing support for them can improve error
reporting for expressions that contain a `:`, e.g. binding to a URL without quotes:
```html
<a [href]="http://google.com">Click me</a>
```
Here, `http` would be parsed as foreign "http" quote expression with `//google.com` as
value, later reporting the error "Quotes are not supported for evaluation!" because
there was no template transform to convert that code.
Closes#40398
PR Close#44915
TypeScript configures `strictNullChecks` to be disabled by default, so the nullish
coalescing check should follow the same default. The rule actively depends on
`strictNullChecks`, as TypeScript doesn't include `null`/`undefined` in its types
otherwise so the check wouldn't have a way to differentiate between them.
This commit also takes the `strict` flag into account when `strictNullChecks` itself
is not configured.
PR Close#44862
The initial commit e9124b42d5 stored the errors rather than
throwing but did not store them in a place that was accessible to consumers. Instead,
the errors should be added to the IndexedComponent so they can be surfaced where the
index results are consumed
PR Close#44884
When the indexer encounters a location where the source span doesn't
match up with the expected identifier, the current visitor code throws
an error. Instead, this change creates an error and moves on to the next
template item. This allows the indexer to continue analysis even when
there are errors in the source mapping. In addition, it still allows callers
to surface those errors in their own way while still providing as much indexed
information as possible about a node.
PR Close#44825
An `ng-template` with an inline template (i.e. has a structural
directive) would previously not get an `undefined` `tagName` because the
logic assumed the element would be `t.Element` or `t.Content` and read
the tag name from the `name` property. For a `t.Template`, this exists
instead on the `t.tagName`. The final result would be an `tagName` of `undefined`
for the parent `t.Template`, causing failures in the indexer downstream.
This `undefined` value is actually expected in the renderer code, even
though the type does not specify this possibility. This change updates
the type of `tagName` to be `string|null` and explicitly handles the
case where there is a structural directive on an `ng-template`. You can
see how the two are differentiated in the compliance code that was
modified in this commit.
PR Close#44788
The previous fix for correcting spans with comments in
59eef29a6c
had the unfortunate side effect of _breaking_ the spans with comments
when there was leading whitespace. This happened because the previous
fix was testing one without a comment, identifying that the offset shouldn't
have anything added to it, and then removing that offset adjustment
(`offsets[i] + (expressionText.length - sourceToLex.length)`).
Upon further investigation, this offset adjustment _was actually
necessary_ for when the input had comments, but this was only because
the `stripComments` function used `trim` to remove whitespace for these
cases. This is the real problem -- not only does it create a ton of confusion
but also it means that the behavior of the lexer and resulting spans is
different between inputs with comments and inputs without comments.
After reviewing how the `inputLength` of `_ParseAST` was used, it
appears that the correct behavior would be to _not_ trim the input. The
`inputLength` is used to advance the current index beyond points which
have been processed. This _should_ include any whitespace. Additionally,
`inputLength` doesn't appear to be needed at all. When there was no
comment in the input, it was always equal to the `input.length` anyways.
When there _is_ a comment, it should include that comment anyways to
advance the index beyond the comment.
PR Close#44785
The original fix for svg elements in
92b23f4851
did not account for svg elements when they also had a structural
directive on them, making the node a template. This resulted in the
logic added in fix above not being applied.
PR Close#44785
Previously, if a bad extended diagnostic category was given, it would fail with the expected error as well as an unexpected assertion error:
```
$ ng build -c development
✔ Browser application bundle generation complete.
./src/main.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: Unexpected call to 'assertNever()' with value:
test
at /home/douglasparker/Source/ng-new/node_modules/@ngtools/webpack/src/ivy/loader.js:77:18
at processTicksAndRejections (internal/process/task_queues.js:95:5)
./src/polyfills.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: Unexpected call to 'assertNever()' with value:
test
at /home/douglasparker/Source/ng-new/node_modules/@ngtools/webpack/src/ivy/loader.js:77:18
at processTicksAndRejections (internal/process/task_queues.js:95:5)
Error: error NG4004: Angular compiler option "extendedDiagnostics.checks['invalidBananaInBox']" has an unknown diagnostic category: "test".
Allowed diagnostic categories are:
warning
error
suppress
```
The assertion comes from `ExtendedTemplateCheckerImpl`, which expects a well-formed configuration, yet the compiler would construct it even when errors were found. This commit skips constructing and running extended diagnostics if the configuration had errors, which should avoid triggering these assertion errors.
I'm unfortunately not able to actually test this change. The test passes even before the fix because the `ngc` binary and end-to-end tests [don't request diagnostics unless the configuration is considered valid](ed21f5c753/packages/compiler-cli/src/perform_compile.ts (L292-L293)). See [Slack](https://angular-team.slack.com/archives/C4WHZQMRA/p1642641305003800) for more details.
PR Close#44778
Refs #42966.
There were two remaining places where `_extendedTemplateDiagnostics` needed to be set which should have been removed in #44712 but got missed. This updates them to only require `strictTemplates` and not `_extendedTemplateDiagnostics` so the feature is properly enabled in production.
PR Close#44777
Refs #42966.
Extended diagnostics provide additional analysis about Angular templates by emitting warnings for specific patterns known to be error prone or cause developer confusion. Currently, there are two such diagnostics which are enabled by default:
* `invalidBananaInBox` emits a warning if a user writes a two-way binding backwards like `([foo])="bar"`, when they actually wanted `[(foo)]="bar"`.
* `nullishCoalescingNotNullable` emits a warning if a binding attempts to perform nullish coalescing (`??`) on a type which does not include `null` or `undefined`, such as `{{ foo ?? 'bar' }}` where `foo` is defined as `string` instead of `string | null`.
These diagnostics are enabled as warnings by default, but this can be configured in the `tsconfig.json` like so:
```jsonc
{
"angularCompilerOptions": {
"extendedDiagnostics": {
// The categories to use for specific diagnostics.
"checks": {
// Maps check name to its category.
"invalidBananaInBox": "suppress"
},
// The category to use for any diagnostics not listed in `checks` above.
"defaultCategory": "error"
}
}
}
```
Allowed categories for a diagnostic are `warning` (default), `error`, or `suppress`. `warning` emits the diagnostic but allows the compilation to succeed, `error` *will* fail the compilation, while `suppress` will ignore the diagnostic altogether.
The initial release has two diagnostics, and we are hoping to expand this longer term to add more diagnostics and provide additional insight into Angular templates to detect and surface developer mistakes *before* hours of debugging are wasted.
PR Close#44712
This commit reduces the analysis work that needs to happen during an
incremental rebuild by properly recording files for which no traits were found
in the set of files that have no traits, such that the same file doesn't have
to be reanalyzed during subsequent rebuilds. It also excludes shim files from
analysis.
PR Close#44731
In the `Element` node of a parsed `<svg>` element, the `name` is recorded
as `:svg:svg`. When the Angular Indexer ran over this element, it would
attempt to find this name in the template text and fail, as the namespace
portion of the name was added automatically at parse time and is of course
missing from the original template.
This commit changes the indexer to detect these namespaced elements and only
search for the tag name.
PR Close#44678
When parsing a binding with a comment at the end of the expression, the
parser previously had logic to offset the parsed spans by the length of the
comment. This logic seemed not to serve any useful purpose, and instead
resulted in the corruption of the spans. For example, in the expression
`{{foo // comment}}`, the parser would map the parsed `foo` `PropertyRead`
node at the location of the characters 'ent' from the comment suffix.
This commit removes that logic, correcting the parsed spans of such nodes in
the presence of comments. Removing this logic does not seem to have caused
any tests to fail.
PR Close#44678
Previously, the Angular Indexer made an assumption that in any binding to
a property of an `ImplicitReceiver`, the property name begins at the start
of the binding. This is true for normal reads from `ImplicitReceiver` as
the implicit receiver has no representation in the template.
However, `ThisReceiver` inherits from `ImplicitReceiver` and _does_ have a
template representation. Such a binding looks like `{{this.foo}}`. This
commit corrects the logic of the indexer to use the `nameSpan` of the
property binding instead of its `sourceSpan` to locate the identifier.
PR Close#44678
Refs #42966.
This validates the `tsconfig.json` options for extended template diagnostics. It verifies:
* `strictTemplates` must be enabled if `extendedDiagnostics` have any explicit configuration.
* `extendedDiagnostics.defaultCategory` must be a valid `DiagnosticCategoryLabel`.
* `extendedDiagnostics.checks` keys must all be real diagnostics.
* `extendedDiagnostics.checks` values must all be valid `DiagnosticCategoryLabel`s.
These include new error codes, each of which prints out the exact property that was the issue and what the available options are to fix them.
It does disallow the config:
```json
{
"angularCompilerOptions": {
"strictTemplates": false,
"extendedDiagnostics": {
"defaultCategory": "suppress"
}
}
}
```
Such a configuration is technically valid and could be executed, but will be rejected by this verification logic. There isn't much reason to ever do this, since users could just drop `extendedDiagnostics` altogether and get the intended effect. This is unlikely to be a significant issue for users, so it is considered invalid for now to keep the implementation simple.
PR Close#44391
Refs #42966.
The `defaultCategory` option is used for any extended template diagnostics which do not have any specific category specified for them. It defaults to `warning`, since that is the most common behavior expected for users. This provides an easy way for users to promote all diagnostics to errors or suppress all diagnostics.
PR Close#44391
Refs #42966.
This updates `TemplateContext` to include a new `makeTemplateDiagnostic()` function which automatically uses the correct diagnostic category for that check. This makes sure that each diagnostic is emitted with the correct category. It also implicitly passes some known values like `component` and `code` to make the extended template diagnostics a little simpler. Diagnostics which are suppressed are never instantiated at all, which acts as a slight performance optimization since any emitted diagnostics would be ignored anyways.
Unfortunately, diagnostics still have access to `ctx.templateTypeChecker.makeTemplateDiagnostic()` to manually create diagnostics with a different category. Both banana in box and nullish coalescing checks include tests to make sure they respect a manually configured category. This convention should hopefully give a reasonable certainty that new diagnostics will use the correct reporting function, even if that is not strictly enforced.
PR Close#44391
Refs #42966.
This includes a mapping of extended template diagnostics to their associated diagnostic category. It is generated from the list of diagnostic names, so the list should always be implicitly kept up to date. Usage looks like:
```json
{
"angularCompilerOptions": {
"extendedDiagnostics": {
"checks": {
"invalidBananaInBox": "error",
"nullishCoalescingNotNullable": "suppress"
}
}
}
}
```
PR Close#44391
Refs #42966.
This is a static array of all the 1P extended template diagnostic factories built into the Angular compiler directly. It provides an encapsulated list of all diagnostics rather than requiring users to manually list each one individually.
PR Close#44391
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
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
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
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
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
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
Prior refactorings caused unexpected g3 sync issues due to a patch that
changes the error documentation URL. This commit moves the base url into
a separate file to make this more apparent.
PR Close#43527
The `ErrorCode` enum in the `error_code.ts` file is governed by public
api guards but the other top-level exports from that file are exempt
from public api documentation and are therefore marked as `@internal`.
However, TypeScript is configured with the `stripInternal` compiler
option such that declarations with `@internal` markers are not emitted
into the `.d.ts` files, but this means that the reexports in the barrel
file end up referring to missing declarations.
The `stripInternal` option is considered internal and its documentation
states to use at your own risk (as per https://github.com/microsoft/TypeScript/issues/45307).
Having the option enabled is desirable for us as it works well for
hiding class fields that are marked `@internal`, which is an effective
way to hide members from the .d.ts file. As a workaround for the issue
with top-level symbols, the declarations with `@internal` markers are
moved to dedicated files for which no public api guard is setup,
therefore allowing their `@internal` markers to be dropped.
Fixes#43097
PR Close#43527
The View Engine compiler now throws when constructed and will be removed shortly. Direct users should switch to `NgtscProgram` to build with [Ivy](https://angular.io/guide/ivy). The View Engine compiler is being removed, so this makes it throw an error to ensure no one accidentally depends on code being removed.
PR Close#43862
Refs #42966.
Previously, a build when emitted one warning and no errors would fail with a non-zero exit code. This is not what users would expect, but had not been an issue before since the compiler did not actually emit any warnings. With upcoming extended template diagnostics and other warnings, this is now a case that needs to be supported. Warnings are printed to `stderr` as before, but `ngc` now exits with code `0` and the build is considered successful.
Implemented this by adding a new `expectedExitCode` parameter to `driveDiagnostics()` which asserts against the real exit code. Most importantly, it does not **require** the the build to pass since any exit code can be given, so it is up to the test to assert this as well as many messages printed to make sure they are acceptable. This is useful for testing warnings and ensuring the build still passes.
PR Close#43673
Bumps the minimum required TypeScript version to 4.4.2 and removes the integration tests for 4.1, 4.2 and 4.3.
BREAKING CHANGE:
TypeScript versions older than 4.4.2 are no longer supported.
PR Close#43642
Refs #42966.
Previously, checking a template with the syntax:
```html
<div>{{ foo() ?? 'test' }}</div>
```
Where `foo()` returns a nullable value:
```typescript
@Component(/* ... */)
class TestCmp {
foo: (): string | null => null;
}
```
Would always log a nullish coalescing not nullable warning. This is because [`getSymbolOfNode(node.left)`](fe69193509/packages/compiler-cli/src/ngtsc/typecheck/extended/checks/nullish_coalescing_not_nullable/index.ts (L30)) would return the [symbol of the function (`foo`)](fe69193509/packages/compiler-cli/src/ngtsc/typecheck/src/template_symbol_builder.ts (L536-L538)) rather than the symbol of its returned value (`foo()`). Fixed this by getting the symbol for the whole expression's span, rather than just the function receiver.
Also made some minor refactorings to `template_symbol_builder` to make a similar change to safe method calls. This behavior was originally for the language service in order to handle quick info, as the user highlighting a function name would actually apply to the entire expression. This is no longer true as the language service will correctly request the type from the function rather than the `Call` expression, so these hacks are not necessary anymore. This broke two existing test cases of exactly this behavior which were easily updated. Also added a test to the language service to confirm that it is not broken by this change.
PR Close#43572
When compiling your application using the AOT compiler, your templates
are type-checked according to a certain strictness level. Before Angular 9
there existed only two strictness levels of template type checking as
determined by [the `fullTemplateTypeCheck` compiler option](guide/angular-compiler-options).
In version 9 the `strictTemplates` family of compiler options has been
introduced as a more fine-grained approach to configuring how strict your
templates are being type-checked.
The `fullTemplateTypeCheck` flag is being deprecated in favor of the new
`strictTemplates` option and its related compiler options. Projects that
currently have `fullTemplateTypeCheck: true` configured can migrate to
the following set of compiler options to achieve the same level of
type-checking.
```json
{
"angularCompilerOptions": {
"strictTemplates": true,
"strictInputTypes": false,
"strictNullInputTypes": false,
"strictAttributeTypes": false,
"strictOutputEventTypes": false,
"strictDomEventTypes": false,
"strictDomLocalRefTypes": false,
"strictSafeNavigationTypes": false,
"strictContextGenerics": false,
}
}
```
PR Close#43224
Similar to the other private entry-points we have added for localize,
bazel or the migrations, we should expose the tooling code through
a dedicated private export. This will make the compiler-cli exports
more consistent and it will become easier for the CLI to export
necessary code.
PR Close#43431
With the APF v13 package output, deep files can no longer be imported.
Since we do not intend to bundle the compiler into the compiler-cli, we
need to switch all deep imports to the primary entry-point.
PR Close#43431
Updates the dynamic-compiler test to be compatible with the APF v13.
As of v13, the packages no longer come with metadata.json files and
now need to be processed with the babel linker plugin. This commit
sets up the linker plugin, and switches away from the deprecated
systemjs approach to a simpler rollup code-splitting variant.
PR Close#43431
Switches the compiler-cli usage of `__filename` to `import.meta.url`
when ESM bundles are generated. Unfortunately we cannot start using
only `import.meta` yet as we still build and run all code in Angular
in CommonJS module output for devmode tests.
This commit also fixes various instances where a jasmine spy was applied on
a namespace export that will break with ES module (and the interop for
CommonJS output). We fix these spies by using a default import.
PR Close#43431
Removes the remaining usages of dynamic require statements in the
package output. Since we declare all shipped packages as strict ESM,
we cannot use dynamic require statements anymore. This commit switches
these usages to actual `import` statements.
Note: Tsickle continues to remain an optional dependency since bundling
does not work with its UMD package output. Also tsickle is rarely used by
consumers, if at all, so bundling does not really provide any significant
value. To continue keeping tsickle optional (since it's still needed by the
`annotateForClosureCompiler` option which is also respected in ngtsc), we
pass-through a tsickle instance as a parameter to `main`. This allows us to
keep the compile functions synchronous without having to refactor the majority
of the watch compilation code, and majority of tests for ngc, ngtsc.
Consumers (like the `ngc` bin entry-point) can then load tsickle based on their
module format. e.g. tsickle can be imported through `require` to keep everything
sync, but in ESM, the dynamic import can be used beforehand to pass `tsickle` to
the `main` function. We can revisit this in the future but for now this does the
trick without exceeding the scope of this commit..
PR Close#43431
As outlined in the previous commit which enabled the `esModuleInterop`
TypeScript compiler option, we need to update all namespace imports
for `typescript` to default imports. This is needed to allow for
TypeScript to be imported at runtime from an ES module.
Similar changes are needed for modules like `semver` where the types incorrectly
suggest named exports that will not exist at runtime when imported from ESM.
This commit refactors all imports to match with the lint rule we have
configured in the previous commit. See the previous commit for more
details on why certain imports have been changed.
A special case are the imports to `@babel/core` and `@babel/types`. For
these a special interop is needed as both default imports, or named
imports break the other module format. e.g default imports would work
well for ESM, but it breaks for CJS. For CJS, the named imports would
only work, but in ESM, only the default export exist. We work around
this for now until the devmode is using ESM as well (which would be
consistent with prodmode and gives us more valuable test results). More
details on the interop can be found in the `babel_core.ts` files (two
interops are needed for both localize/or the compiler-cli).
PR Close#43431
The Angular Core and localize package currently use deep imports for
code that is shipped. This is problematic as we want to ship the
compiler-cli as full-ESM. To achieve this we need to use a bundler and
this breaks deep imports.
We use a bundler for the compiler CLI because for full ESM
compatibility, we would need to explicitly add the `.js` extension
to all relative imports. This is very cumbersome and prone to mistakes
so to mitigate this problem in a safe way, we bundle the compiler-cli.
Note: Deep imports continue to exist for the language service as it
bundles the compiler-cli.
PR Close#43431
As part of APF v13, we ship Angular framework packages using partial
compilation. This is done in preparation of VE removal, and to
eventually get rid of `ngcc` processing.
The new library format allows libraries to switch away from the View
Engine package format without shipping Angular definitions with
instructions to NPM. This would make libraries tightly coupled to
specific versions of `@angular/core`.
Since Angular core is always compatible with itself, we always should
compile Angular core using full compilation mode. It is unreasonable
to ship Angular core with partial compilation output, especially since
we would need to export the linker `declare` functions in
`r3_symbols.ts` otherwise.
PR Close#43431
All other frameworks packages are now using APF v13 and are strict
ESM packages. The compiler-cli does not use APF and is currently shipped
with its devmode ES5 CommonJS sources. This is problematic as CommonJS
cannot simply import from ECMAScript modules (like `@angular/compiler`).
To fix this we use a bundler that allows us to ship the compiler-cli as
a strict ESM package. Note: An ESM can import from an ESM without any
problems. This is what we need hre.
Unfortunatley we need a bundler here because converting the compiler-cli
to ESM is non-trivial as relative imports would need an explicit
`.js` extension. This work can be simplified by using a bundler that
avoids relative imports completely.
Note: This commit uses code-splitting to create multiple bundle
entry-points for `yarn ngc, `yarn ngcc` etc. This commit removed
the old `ivy-ngcc` entry-point that just printed an error message
(to reduce amount of bundles having to be configured).
PR Close#43431
With the changes to support APF v13 in the `ng_package` rule, we have
removed the ambiguous `entry_point` attribute. The attribute suggested
that it would be used for determining the primary entry-point input
file. This was not the case as the flat module output file is consulted
for bundling et at. The attribute has been renamed to match its
purposed (renamed to `primary_bundle_name`).
We no longer need to set that attribute because the primary bundle
name is (1) not of relevance for consumers and (2) the rule already
infers the bundle name properly from the Bazel package.
PR Close#43431
Now that `Route.loadChildren` no longer accepts a string, there is no
need for tooling to find all string-based `loadChildren` to setup lazy
imports for them. As a result, the `listLazyRoutes` operation that
enumerates all string-based `loadChildren` occurrences is no longer
needed and is therefore removed from the compiler.
The `listLazyRoutes` API remains on the `Program` interface to avoid
breaking external tools that may be using this method, but those tools
should ultimately move away from using this API.
PR Close#43591
When specifying the `deps` array in the `@Injectable` decorator to
inject dependencies into the injectable's factory function, it should
be possible to use an array literal to configure how the dependency
should be resolved by the DI system.
For example, the following example is allowed:
```ts
@Injectable({
providedIn: 'root',
useFactory: a => new AppService(a),
deps: [[new Optional(), 'a']],
})
export class AppService {
constructor(a) {}
}
```
Here, the `'a'` string token should be injected as optional. However,
the AOT compiler incorrectly used the array literal itself as injection
token, resulting in a failure at runtime. Only if the token were to be
provided using `[new Optional(), new Inject('a')]` would it work
correctly.
This commit fixes the issue by using the last non-decorator in the
array literal as the token value, instead of the array literal itself.
Note that this is a loose interpretation of array literals: if a token
is omitted from the array literal then the array literal itself is used
as token, but any decorator such as `new Optional()` would still have
been applied. When there's multiple tokens in the list then only the
last one will be used as actual token, any prior tokens are silently
ignored. This behavior mirrors the JIT interpretation so is kept as is
for now, but may benefit from some stricter checking and better error
reporting in the future.
Fixes#42987
PR Close#43226
Native DOM events were previously not included in the completions
because the dom schema registry would filter out events completely. This
change updates the registry to include events in the private
element->property map and excludes events from lookups outside of the
new `allKnownEventsOfElement` function.
fixes https://github.com/angular/vscode-ng-language-service/issues/1479
PR Close#43299
Adds support for TypeScript 4.4. High-level overview of the changes made in this PR:
* Bumps the various packages to `typescript@4.4.2` and `tslib@2.3.0`.
* The `useUnknownInCatchVariables` compiler option has been disabled so that we don't have to cast error objects explicitly everywhere.
* TS now passes in a third argument to the `__spreadArray` call inside child class constructors. I had to update a couple of places in the runtime and ngcc to be able to pick up the calls correctly.
* TS now generates code like `(0, foo)(arg1, arg2)` for imported function calls. I had to update a few of our tests to account for it. See https://github.com/microsoft/TypeScript/pull/44624.
* Our `ngtsc` test setup calls the private `matchFiles` function from TS. I had to update our usage, because a new parameter was added.
* There was one place where we were setting the readonly `hasTrailingComma` property. I updated the usage to pass in the value when constructing the object instead.
* Some browser types were updated which meant that I had to resolve some trivial type errors.
* The downlevel decorators tranform was running into an issue where the Closure synthetic comments were being emitted twice. I've worked around it by recreating the class declaration node instead of cloning it.
PR Close#43281
Adds a test to the nullish coalescing diagnostic check to serve as
self-documentation on how it works with nullish coalescing on pipes that
are often misconfigured.
This also removes that non null assertion operator, which is incorrect
because there _are_ situations where a symbol cannot be retrieved.
PR Close#43419
Currently the compiler has three different classes to represent a "call to something":
1. `MethodCall` - `foo.bar()`
2. `SafeMethodCall` - `foo?.bar()`.
3. `FunctionCall` - Any calls that don't fit into the first two classes. E.g. `foo.bar()()`.
There are a few problems with this approach:
1. It is inconistent with the TypeScript AST which only has one node: `CallExpression`.
2. It means that we have to maintain more code, because the various parts of the compiler need to know about three node types.
3. It doesn't allow us to easily implement some new JS features like safe calls (e.g. `foo.bar?.())`).
These changes rework the compiler so that it produces only one node: `Call`. The new node behaves similarly to the TypeScript `CallExpression` whose `receiver` can be any expression.
There was a similar situation in the output AST where we had an `InvokeMethodExpression` and `InvokeFunctionExpression`. I've combined both of them into `InvokeFunctionExpression`.
PR Close#42882
The template type-checker has to emit type constructors for the
directives that are used in a template, where a type constructor's
declaration has to mirror the type parameter constraints as they were
originally declared. Therefore, the compiler analyzes whether a type
parameter constraint can be recreated, e.g. by generating imports for
any type references. Some type references cannot be recreated, in which
case the compiler has to fall back to a strategy where the type
constructor is created inline in the original source file (which comes
with a performance penalty).
There used to be an issue for type references to namespaced declarations.
The compiler is unable to emit such references such that an inline
type constructor should be used as fallback, but this did not happen.
This caused the attempt to emit the type reference to fail, as the
namespaced declaration cannot be located by the reference emitters.
This commit fixes the issue by using a stricter check to determine if a
type parameter requires an inline type constructor. The TypeScript
reflection host's `isStaticallyExported` logic was expanded to work for
any declaration instead of just classes, as e.g. type declarations can
also be referenced in a type parameter constraint.
Closes#43383
PR Close#43511
Add an abstract class that has a default implementation of the run
function and visits all nodes. Authors of template checks can extend
this class and override the `visitNode` method to return diagnostics.
Refs #42966
PR Close#43232
Previously, the decorator transformer was annotating the synthesized properties with TS type annotations. However, because it ran after the JSDoc transformer, the TS types were just dropped from the emitted JS. Attempting to move the decorator transformer before the JSDoc transformer causes tsickle crashes because synthetic AST fragments are not attached to a SourceFile node.
PR Close#43021
Add the call to get the extended template diagnostics in
the compiler's `getDiagnosticsForComponent`. This makes showing
extended diagnostics in non-ts files posible.
Refs #42966
PR Close#43134
Rename `getExtendedTemplateDiagnosticsForComponent` to
`getDiagnosticsForComponent` since it's implied they are extended
diagnostics.
Refs #42966
PR Close#43134
Return `TemplateDiagnostic` instead of `ts.Diagnostic` when getting the
extended template diagnostics. This makes the integration with the
language service easier. This also fixes the error code and now uses the
`ngErrorCode` for extended template diagnostics.
Refs #42966
PR Close#43134
This commit integrates extended template checks with the compiler, by
adding another phase of diagnostics generation. This integration is
under the `_extendedTemplateDiagnostics` flag.
Refs #42966
PR Close#43107
This commit exports the implementation of `ExtendedTemplateChecker` to
generate extended template diagnostics and all the template checks.
Refs #42966
PR Close#43107
Change the current way to run template checks to the
`ExtendedTemplateChecker` instead of just the
`getExtendedTemplateDiagnosticsForComponent` function. Refactored the
tests that used the previous function to use the new class.
Refs #42966
PR Close#43107
Previously with View Engine output, the `enableResourceInlining` option
could be set to inline external templates and styles (also for the
resulting `.metadata.json` files). We want to do the same for the Ivy
compilation pipeline (regardless of the compilation mode). The full
compilation definitions, and partial declarations currently already
inline resources in a way that no external requests need to be made.
Although there is one exception currently. These are the calls for
setting class metadata (for testbed overrides). This commit updates
the set class metadata calls (for both partial and full compilation)
to always inline resources. This means that libraries do not need
to start shipping external styles/templates just for the
`setClassMetadata` calls.
Note: Only doing this for partial compilation has been considered, but
it seems like it would be simpler implementation-wise to do this for
full compilation as well. Given the external resources are already
inlined (through their `ecmp` definitions), it seems acceptable (or
even more aligned) to do the same for the set class metadata calls.
PR Close#43178
Add the implementation of a Template Check that ensures the correct
use of two-way binding syntax. Generates a warning when
'([foo])="bar"' is found instead of '[(foo)]="bar"'.
Refs #42966
PR Close#42984
Export `getSourceCodeForDiagnostic` from `ngtsc/testing` to make it
available for other packages. This will help confirm that the source
code is correct in other tests.
Refs #42966
PR Close#42984
This commit moves the test utils used in the typechecking tests into its
own package. This makes them available to be used in the tests of a
different package.
Refs #42966
PR Close#42984
specific
This commit makes the wrapper function `makeTemplateDiagnostic` take an
ErrorCode as a type for the `ts.Diagnostic`s to be generated.
Refs #42966
PR Close#42984
This commit introduces //packages/compiler-cli/src/ngtsc/typecheck/extended
as a container for a new phase of diagnostics generation. The API provides an
interface for new template checks to implement and generate template diagnostics.
Refs #42966
PR Close#42984
When the user tries to trigger suggestions from an interruption,
the LS should provide the global completions. For example,
`[input]="t¦"`, the `t` can be the `true` or the symbol from
the component context.
PR Close#42923
Add a `makeTemplateDiagnostic` wrapper in the `TemplateTypeChecker`. This requiers less parameters to create template diagnostics, since the `TemplateTypeChecker` can get the templateId and mapping from it's scope with the `ts.ClassDeclartion`. The `TemplateTypeChecker` is often used to determine if a diagnostic should be produced, so it makes sense to have a function in it that helps create them.
Refs #42966
PR Close#42937
The compiler keeps track of how a declaration has been referenced
using absolute module imports and from which path the absolute module
should be resolved from. There was a bug in how the .d.ts metadata
extraction would incorrectly use the .d.ts file itself as resolution
context for symbols that had been imported using a relative module
specifier. This could result in module resolution failures.
For example, when extracting NgModule metadata from
`/node_modules/lib/index.d.ts` that looks like
```
import {LibDirective} from './dir';
@NgModule({
declarations: [LibDirective],
exports: [LibDirective],
})
export class LibModule {}
```
and `/app.module.ts` that contains
```
import {LibModule} from 'lib';
@NgModule({
imports: [LibModule],
})
export class AppModule {}
```
then `AppModule` would have recorded a reference to `LibModule` using
the `'lib'` module specifier. When extracting the NgModule metadata from
the `/node_modules/lib/index.d.ts` file the relative import into `./dir`
should also be assumed to be importable from `'lib'` (according to APF
where symbols need to be exported from a single entry-point)
so the reference to `LibDirective` should have `'lib'` as absolute
module specifier, but it would incorrectly have
`/node_modules/lib/index.d.ts` as resolution context path. The latter is
incorrect as `'lib'` needs to be resolved from `/app.module.ts` and not
from within the library itself.
Fixes#42810
PR Close#42879
In an incremental rebuild, the compiler attempts to reuse as much
analysis data from a prior compilation as possible to avoid doing the
analysis work again. For source files without Angular behavior however,
no analysis data would be recorded such that the source file had to be
reanalyzed each rebuild, even if it has not changed.
This commit avoids the analysis of such source files by registering
these files as not containing any Angular behavior; allowing subsequent
rebuilds to avoid the analysis work.
PR Close#42562
The static interpreter assumed that a foreign function expression would
have to be imported from the absolute module specifier that was used for
the foreign function itself. This assumption does not hold for the
`forwardRef` foreign function resolver, as that extracts the resolved
expression from the function's argument, which is not behind the
absolute module import of the `forwardRef` function.
The prior behavior has worked for the typical usage of `forwardRef`,
when it is contained within the same source file as where the static
evaluation started. In that case, the resulting reference would
incorrectly have an absolute module guess of `@angular/core`, but the
local identifier emit strategy was capable of emitting the reference
without generating an import using the absolute module guess.
In the scenario where the static interpreter would first have to follow
a reference to a different source that contained the `forwardRef` would
the compilation fail. In that case, there is no local identifier
available such that the absolute module emitter would try to locate the
imported symbol from `@angular/core`. which fails as the symbol is not
exported from there.
This commit fixes the issue by checking whether a foreign expression
occurs in the same source file as the call expression. If it does, then
the absolute module specifier that was used to resolve the call
expression is ignored.
Fixes#42865
PR Close#42887
For the compilation of a component, the compiler verifies that the
imports it needs to generate to reference the used directives and pipes
would not create an import cycle in the program. This requires visiting
the transitive import graphs of all directive/pipe usage in search of
the component file. The observation can be made that all directive/pipe
usages can leverage the exploration work in search of the component
file, thereby allowing sub-graphs of the import graph to be only visited
once instead of repeatedly per usage. Additionally, the transitive
imports of a file are no longer collected into a set to reduce memory
pressure.
PR Close#41271
In #41995 the type of `TrackByFunction` was changed such that the
declaration of a `trackBy` function did not cause the item type to be
widened to the `trackBy`'s item type, which may be a supertype of the
iterated type. This has introduced situations where the template type
checker is now reporting errors for cases where a `trackBy` function is
no longer assignable to `TrackByFunction`.
This commit fixes the error by also including the item type `T` in
addition to the constrained type parameter `U`, allowing TypeScript to
infer an appropriate `T`.
Fixes#42609
PR Close#42692
In combination with the TS `noImplicitOverride` compatibility changes,
we also want to follow the best-practice of adding `override` to
members which are implemented as part of abstract classes. This
commit fixes all instances which will be flagged as part of the
custom `no-implicit-override-abstract` TSLint rule.
PR Close#42512
In #42492 the template type checker became capable of replicating a
wider range of generic type parameters for use in template type-check
files. Any literal types within a type parameter would however emit
invalid code, as TypeScript was emitting the literals using the text as
extracted from the template type-check file instead of the original
source file where the type node was taken from.
This commit works around the issue by cloning any literal types and
marking them as synthetic, signalling to TypeScript that the literal
text has to be extracted from the node itself instead from the source
file.
This commit also excludes `import()` type nodes from being supported,
as their module specifier may potentially need to be rewritten.
Fixes#42667
PR Close#42761
Updates the Bazel NodeJS rules to v4.0.0-beta.0. This is necessary
so that the Angular components repo can update, and it's generally
good to stay as up-to-date as possible with the Bazel rules as it's
easy to fall behind, and updating early allows us to discover issues
affecting our tooling earlier (where they are easier to address due to
e.g. potential breaking change policy).
PR Close#42760
Source files that contain directives or components that need an inline
type constructor or inline template type-check block would always be
considered as affected in incremental rebuilds. The inline operations
cause the source file to be updated in the TypeScript program that is
created for template type-checking, which becomes the reuse program
in a subsequent incremental rebuild.
In an incremental rebuild, the source files from the new user program
are compared to those from the reuse program. The updated source files
are not the same as the original source file from the user program, so
the incremental engine would mark the file which needed inline
operations as affected. This prevents incremental reuse for these files,
causing sub-optimal rebuild performance.
This commit attaches the original source file for source files that have
been updated with inline operations, such that the incremental engine
is able to compare source files using the original source file.
Fixes#42543
PR Close#42759
DTS bundling, will cause originally namespaced imports become namespace declarations within the same file. Example:
Before bundling
```ts
import * as i1 from './router';
export declare class RouterModule {
constructor(guard: any, router: Router);
static ɵmod: i0.ɵɵNgModuleDeclaration<RouterModule, [typeof i1.RouterOutlet...]>;
}
```
After bundling
```
declare namespace i1 {
export {
RouterOutletContract,
RouterOutlet
}
}
export declare class RouterModule {
constructor(guard: any, router: Router);
static ɵmod: i0.ɵɵNgModuleDeclaration<RouterModule, [typeof i1.RouterOutlet...]>;
}
```
And therefore this commit adds support for reflecting types that are defined in such namespace declarations.
Closes#42064
PR Close#42728
When the template type checker try to get a symbol of a template node, it will
not return the directives intended for an element on a microsyntax template,
for example, `<div *ngFor="let user of users;" dir>`, the `dir` will be skipped,
but it's needed in language service.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1420
PR Close#42640
Adds support for shorthand property declarations inside Angular templates. E.g. doing `{foo, bar}` instead of `{foo: foo, bar: bar}`.
Fixes#10277.
PR Close#42421
Previously, the template type checker would only opt-in to inline type
constructors if it could import all type references from absolute module
specifiers. This limitation was put into place in an abundance of
caution as there was a safe, but less performant, fallback available.
The language service is not capable of using this fallback, which now
means that the limitation of absolute module specifiers limits the
language service's ability to use accurate types for component/directive
classes that have generic type parameters.
This commit loosens the restriction such that type references are now
eligible for emit as long as they are exported.
PR Close#42492
When a component/directive has a generic type parameter, the template
type checker attempts to translate the type parameter such that the
type parameters can be replicated in the type constructor that is
emitted into the typecheck file.
Type parameters with a default clause would incorrectly be emitted into
the typecheck file using the original `ts.TypeNode` for the default
clause, such that `ts.TypeReferenceNode`s within the default clause
would likely be invalid (i.e. referencing a type for which no import is
present in the typecheck file). This did not result in user-facing
type-check errors as errors reported in type constructors are not
translated into template positions Regardless, this commit ensures that
`ts.TypeReferenceNode`s within defaults are properly translated into the
typecheck file.
PR Close#42492
