For the HMR initializer block to support being used in a Vite setup with
import analysis, the import call expression needs to be a runtime generated
value and include the `@vite-ignore` special comment. Without the first,
Vite will error prior to loading the application. Without the second, a
warning will be shown for each import which is effectively each component
within the application when HMR is enabled.
PR Close#58173
We're using `path.relative` to compute a relative path between a `SourceFile` and the one of the `rootDirs`. The problem is that the `rootDirs` get passed through `getCanonicalFileName` which lowercases the path in some platforms, while `SourceFile.fileName` is always case-insensitive. This yields a path outside of the project which we were ignoring.
This change passes the `SourceFile.fileName` before passing it through `path.relative` to ensure that we get a valid result.
PR Close#58150
Consider a template with a context variable `a`:
```
<ng-template let-a>{{this.a}}</ng-template>
```
t push -fAn interpolation inside that template to `this.a` should intuitively read the class variable `a`. However, today, it refers to the context variable `a`, both in the TCB and the generated code.
In this commit, the above interpolation now refers to the class field `a`.
BREAKING CHANGE: `this.foo` property reads no longer refer to template context variables. If you intended to read the template variable, do not use `this.`.
Fixes#55115
PR Close#55183
Currently we don't defer any symbols that have references outside of the `import` statement and the `imports` array. This is a bit too aggressive, because it's possible that the symbol is only used for types (e.g. `viewChild<SomeCmp>('ref')`) which will be stripped when emitting to JS.
These changes expand the logic so that references inside type nodes aren't considered.
**Note:** one special case is when the symbol used in constructor-based DI (e.g. `constructor(someCmp: SomeCmp)`, because these constructors will be compiled to `directiveInject` calls. We don't need to worry about them, because the compiler introduces an addition `import * as i1 from './some-cmp';` import that it uses to refer to the symbol.
Fixes#55991.
PR Close#58104
To ensure that the external runtime style component feature is correctly
emitted by the Angular compiler, compliance tests have been added for
file-based component styles. Additionally, the partial golden generator
has been updated to work with file-based component styles.
PR Close#57613
Some apps follow a pattern where they have an array of common declarations which is imported in most standalone components, but only some of the declarations are used. Such cases will currently raise the unused imports diagnostic but can be hard to fix, because it would require either removing declarations from the common array which can break other components, or copying only the necessary declarations from the array. Since neither of these solutions is great, this commit tweaks the logic for the diagnostic so that unused imports coming from _exported_ arrays are not reported (either from the same file or another one).
PR Close#57940
Add the `strictStandalone` flag to `angularCompilerOptions`. When set to
true, the compiler will require that all declarations of components,
directive, and pipes be standalone. When `standalone: false` is provided,
an error is raised.
Note that until the default value of the standalone flag is flipped, this
does not catch the case where a declaration does not specify a value for
`standalone`.
The default value of the `strictStandalone` flag is `false`.
PR Close#57935
Finalizes compiler implementation of the new `hydrate` triggers by:
* Reworking the logic that was depending on the `hydrateSpan` to distinguish hydrate triggers from non-hydrate triggers.
* Fixing that the `hydrate when` trigger didn't have a `hydrateSpan`.
* Adding an error if a parameter is passed into a `hydrate` trigger.
* Add an error if other `hydrate` triggers are used with `hydrate never`.
* Replacing the `prefetch` and `hydrate` flags in the template pipeline with a `modifiers` field.
* Fixing an error that was being thrown when reifying `hydrate` triggers in the pipeline.
* Adding quick info support for the `hydrate` keyword in the language service.
* Adding some tests for the new logic.
PR Close#57831
Adds a new diagnostic that will report cases where a declaration is in the `imports` array, but isn't being used anywhere. The diagnostic is reported as a warning by default and can be controlled using the following option in the tsconfig:
```
{
"angularCompilerOptions": {
"extendedDiagnostics": {
"checks": {
"unusedStandaloneImports": "suppress"
}
}
}
}
```
**Note:** I'll look into a codefix for the language service in a follow-up.
Fixes#46766.
PR Close#57605
This commit changes the structure of the API extraction files to include all symbols used inside a package.
The structure is a `Map`, Symbol => package
eg: 'ApplicationRef' => '@angular/core'
PR Close#57346
in order for the docs to process function entry, this commit refactor function extraction by keeping the implementation as a the default entry and adds all the overloads into a separate array of entries.
PR Close#56489
Currently we use some short variable names like `t` and `r` in the generated factory functions. They can conflict with local symbols with the same names, if they're used for DI.
These changes rename the parameters to reduce the change for conflicts.
Fixes#57168.
PR Close#57181
This commit is similar to 98ed5b609e, and
makes use of the preparation work implemented there.
Similar to directives and components marked via `jit: true`, we also
need to do the same for JIT marked `@NgModule` classes. This is mostly
important for downleveling of decorators to support dependency injection
of such classes.
Inside Google3, migrating from `ts_library` to `ng_module` turns of
decorator downleveling, so the `jit: true` for NgModule's is implicitly
requesting/reliant on this transform— as expected.
PR Close#57212
Currently we use some short variable names like `t` and `r` in the generated factory functions. They can conflict with local symbols with the same names, if they're used for DI.
These changes add a `ɵ` to the generated variables to reduce the chance of conflicts.
Fixes#57168.
PR Close#57181
Adds a new extended diagnostic that will flag `@let` declarations that aren't used within the template. The diagnostic can be turned off through the `extendedDiagnostics` compiler option.
PR Close#57033
Some Angular template instructions that follow each other may be chained
together in a single expressions statement, containing a deeply nested
AST of call expressions. The number of chained instructions wasn't previously
limited, so this could result in very deep ASTs that cause stack overflow
errors during TypeScript emit.
This commit introduces a limit to the number of chained instructions to
avoid these problems.
Closes#57066
PR Close#57069
Adds a new extended diagnostic that will flag `@let` declarations that aren't used within the template. The diagnostic can be turned off through the `extendedDiagnostics` compiler option.
PR Close#57033
This commit moves the JIT transforms into the ngtsc folder. They existed
outside of ngtsc mostly as an historic artifact— and now with compiler
relying on them even more deeply, it makes sense to move them into
`ngtsc/transform`.
PR Close#56892
Currently when compiling code with the Angular compiler, all classes
with Angular decorators are compiled with AOT. This includes type
checking, scope collection etc.
This may not be desirable for all components, e.g. dynamic components,
or test components w/ `TestBed.configureTestingModule` (if compiled with ngtsc).
Those components can opt out of AOT on a per component-basis via `jit:
true`. This is helpful as it allows incremental migrations/refactorings
to AOT. Whether we want to keep this capability long-term is something
to be discussed separately.
For now though, we should fix that components compiled with `jit: true`
actually work as expected. Currently this **not the case** as soon as
the new initializer APIs are used— as those do no longer declare class
metadata with decorators.
This commit runs the JIT transform on JIT-opted classes.
Related: https://docs.google.com/document/d/1ox4atCJldWWDXlaYgwM-hU8BNsTpKNW7gx8OfZ0HtRY/edit?resourcekey=0-G1haTNYtD-dN0vNRkQ8_OQ&tab=t.0
PR Close#56892
When we process `@if` and `@for` blocks, we create a scope around their expressions in order to encapsulate the aliases to them. The problem is that this doesn't represent the actual structure since the expression is part of the outer scope. This surfaces by not raising the "used before declared" diagnostic for `@let` declarations.
These changes resolve the issue by processing the expression as a part of the parent scope.
Fixes#56842.
PR Close#56843
Currently the logic that maps a name to a variable looks at the variables in their definition order. This means that `@let` declarations from parent views will always come before local ones, because the local ones are declared inline whereas the parent ones are hoisted to the top of the function.
These changes resolve the issue by giving precedence to the local variables.
Fixes#56737.
PR Close#56752
When running the JIT transforms in 1P w/ tsickle, tsickle will
transform source files before our custom transforms can run. This is
also impacting the Ivy transform and hence we use `ts.getOriginalNode`
in various places to inspect the source AST for detecting Angular.
For the JIT transform we need to do a similar change so that the
transform could run in 1P.
PR Close#56520
Enables the new `@let` syntax by default.
`@let` declarations are defined as:
1. The `@let` keyword.
2. Followed by one or more whitespaces.
3. Followed by a valid JavaScript name and zero or more whitespaces.
4. Followed by the `=` symbol and zero or more whitespaces.
5. Followed by an Angular expression which can be multi-line.
6. Terminated by the `;` symbol.
Example usage:
```
@let user = user$ | async;
@let greeting = user ? 'Hello, ' + user.name : 'Loading';
<h1>{{greeting}}</h1>
```
Fixes#15280.
PR Close#56715
These changes integrate let declarations into the template pipeline. This involves a few operations:
* Producing a `declareLet` instruction call at creation time to initialize the declaration.
* Producing a `storeLet` instruction call in the place of the let declaration, including the necessary `advance` calls beforehand.
* For let declarations used within their declaration view, moving the `const` to be placed right after the `storeLet` call to ensure the their value has been computed.
* For let declarations that are _only_ used in their declaration view, removing the `storeLet` call and inlining the expression into the constant statement.
PR Close#56299
Updates the check that prevent writes to template variables in two-way bindings to account for let declarations.
Also fixes some old tests that weren't properly setting up two-way bindings.
PR Close#56199
Integrates let declarations into the template type checker by producing corresponding constants in the TCB.
This also includes a couple of custom diagnostics to flag usages of let before they're declared and illegal writes to let declarations. We can't rely on TS for these checks, because it includes the variable name in the diagnostic.
PR Close#56199
Currently the template syntax errors are extracted in the template type check phase. But in local compilation mode we skip the type check phase. As a result template syntax errors are not displayed. With this change we show the template syntax diagnostics in local mode.
PR Close#55855
