Fixes that the logic recognizing initializer APIs didn't account for the expression being wrapped in an `as` expresion or in a parenthesized expression. This was already accounted for in the diagnostic so these changes align the behavior between them.
Fixes#62197.
PR Close#62203
Currently we have a `ParserError` that is used for the expression parser and a `ParseError` that is used everywhere else. These changes consolidate them into the `ParseError` to avoid confusion and make it easier to add more context in the future.
PR Close#62160
Adds a field to the directive's metadata tracking whether it has directive dependencies. Knowing this will allow the pipeline to decide whether to produce DOM-only or full instructions.
PR Close#62096
In the initial implementation for experimental fast type declaration
emission introduced in e62fb35, external references in host directives
were not supported at all.
This change adds support for direct external references in host
directives. Any other expressions indirectly using external references
are still not supported.
PR Close#61469
The Angular class metadata emit structure does not support the use of
private fields. If the class metadata emit is enabled and an ECMAScript
private (i.e., `#` prefixed) member contains a decorator, the member will
now be excluded from the emitting `setClassMetadata` call. This prevents
runtime errors due to invalid syntax.
PR Close#61227
In declaration-only emission mode, the compiler extracts the type
declarations (.d.ts) files without full type-checking, which is possible
with sufficient type annotations on exports that can be ensured by the
`isolatedDeclarations` TS compiler option.
This allows us to decouple type declaration emission from the actual
full compilation doing the type-checking, thereby removing the
edge between dependent TS files in the build action graph. In other
words, the compilation of a TS file no longer indirectly depends on the
compilation of all the TS files it imports through its dependency on
their type declarations, because the type declarations themselves no
longer depend on the compilation of their associated TS file.
Without the coupling between type declaration emission and compilation,
compilation time of a TS project is no longer bound dependent on the
depth of the TS dependency tree as we can now build the entire project
with just two entirely parallel phases: 1) emit the type declarations of
all TS files in parallel and 2) compile all TS files in parallel.
Since the Angular compiler adds static metadata fields to components,
directives, modules, pipes and services based on their respective class
annotations, it needs to actively partake in the type declaration
emission in order to provide the types for these static fields in the
declaration.
In this change, we add experimental support for a declaration-only
emission mode based on the local compilation mode, which already
operates without type-checking and access to external type information,
i.e. the same environment as is required for declaration-only emisssion.
Apart from the same restrictions applied in local compilation mode,
there are a few more restrictions imposed on code being compatible with
this initial and experimental implementation:
* No support for `@NgModule`s using external references.
* No support for `hostDirectives` in `@Component`s and `@Directive`s
using external references
* No support for `@Input` annotations with `transform`.
PR Close#61334
As part of the Bazel toolchain migration we noticed that implicit types
generated by the TypeScript compiler sometimes end up referencing types
from other packages (i.e. cross-package imports).
These imports currently work just because the Bazel `ts_library` and
`ng_module` rules automatically inserted a `<amd-module
name="@angular/x" />` into `.d.ts` of packages. This helped TS figure
out how to import a given file. Notably this is custom logic that is not
occuring in vanilla TS or Angular compilations—so we will drop this
magic as part of the toolchain cleanup!
To improve code quality and keep the existing behavior working, we are
doing the following:
- adding a lint rule that reduces the risk of such imports breaking. The
failure scenario without the rule is that API goldens show unexpected
diffs, and types might be duplicated in a different package!
- keeping the `<amd-module` headers, but we manually insert them into
the package entry-points. This should ensure we don't regress
anywhere; while we also improved general safety around this above.
Long-term, isolated declarations or a lint rule from eslint-typescript
can make this even more robust.
PR Close#61312
In the event of an invalid `schemas` field for an Angular module, an
empty schema array will now be used instead of a fatal error occurring.
A build will still fail in this case with the error reported as a
diagnostic. However, for the language service, this allows the module
to exist in the compiler registry and prevents cascading diagnostics
within an IDE due to "missing" modules/components. The originating
schema related errors will still be reported in the IDE.
PR Close#61220
We have several cases where we need a visitor that traverses both the template and expression ASTs fully. Currently we're re-implementing the visitor each time which means that we need to update multiple visitors every time something changes.
These changes add a single base class that we can reuse to simplify such cases in the future.
PR Close#61158
Fixes that we weren't emitting references to selectorless pipes, because we were checking the name of the pipe, rather than the local name of the symbol.
PR Close#61100
These changes connect the dependency analysis data from the previous commits with the template type checker which allows us to fully type check a selectorless component.
Also includes tests for all of the new selectorless behaviors that have been introduced so far.
PR Close#61100
The `ComponentHandler.resolve` method is ~500 lines and is a bit hard to follow due to some very long `if` statements. These changes split the functionality across several smaller methods to make it easier to manage.
PR Close#61018
Currently to create an `R3TargetBinder`, we have to pass some sort of directive matcher, however we also have a couple of use cases where we use the binder to do analysis that's unrelated to directives (e.g. resolving the `@defer` blocks). In these cases having to create a dummy matcher adds some slight overhead and makes the code harder to reason about since it looks like directive matching may be happening.
These changes update the `R3TargetBinder` to allow for `null` to be passed as the directive matcher.
PR Close#61018
Updates the target binder to allow either a selector-based or selectorless matcher to be passed in. This will allow us to skip some of the overhead when matching directives to nodes.
PR Close#60952
Currently when an incorrect value is in the `imports` array, we highlight the entire array which can be very noisy for large arrays. This comes up semi-regularly (at least for me) when an import is missing.
These changes add some logic that reports a more accurate diagnostic location for the most common case where the `imports` array is static. Non-static arrays will fall back to the current behavior.
PR Close#60455
Sets up the logic that produces the information necessary to type check host bindings of a component. Also introduces a compiler flag for toggling checking of host bindings.
PR Close#60267
Instead of relying on Microsoft's API extractor for `d.ts` bundling,
we are switching to Rollup-based `.d.ts` bundling.
This allows us to support code spliting, even for `.d.ts` files,
allowing for relative imports to be used between entry-points, without
ending up duplicating `.d.ts` definitions in two files. This would otherwise cause
problems with assignability of types.
It also nicely integrates into our existing rollup configuration, and
overall simplifies the `ng_package` rule even further!
Notably `tsup` also uses this rollup plugin, and it seems to work well.
Keep in mind that Microsoft's API extractor is pretty hard to integrate,
caused many problems in the past, and isn't capable of code splitting.
This aligns our d.ts bundling with the .mjs bundling (great alignment).
PR Close#60321
We had several places where we were trying to get the source file of a class for which we're generating HMR-related code. These calls will fail if the class was transformed so we have to get its source file through the original node.
Fixes#60287.
PR Close#60298
A build will still fail in this case. However, for the language service,
this allows the component to exist in the compiler registry and prevents
cascading diagnostics within an IDE due to "missing" components. The
originating template related errors will still be reported in the IDE.
This case is particularly important when a template file either does
not exist or is inaccessible to the language service.
PR Close#58673
Previously we never could use relative imports to import e.g. `Component`
in e.g. the `core/tests/bundling` folder. This was necessary because otherwise the
Angular compiler wouldn't process those files as it wouldn't recognize
the Angular decorator as the one from `@angular/core`.
Notably this still isn't a large issue because relative imports still
work for most core tests, that are JIT compiled!
For bundling tests though, or some smaller targets, our new upcoming
guidelines for using relative imports inside the full package; fall
apart. This commit unblocks this effort and allows us to use relative
imports in all tests of `packages/core`. This is achieved by leveraging
the existing `isCore` functionality of the compiler, and fixing a few
instances that were missing before.
PR Close#60268
Currently only components can have resources, because they're the only symbol kinds being type checked. Since we want to add directives to it, these changes rework the resource handling to accommodate them.
PR Close#60191
Currently a lot of the internal type checking data structures are set up specifically for components, because we only support type checking of templates. Since this will change in future commits, these changes prepare for it by renaming various methods and separating out component-specific data.
PR Close#60191
When the compiler analyzes the defer blocks in a component, it generates two sets of dependencies: ones specific for each block and others from all the deferred blocks within the component. The logic that combines all the defer block dependencies wasn't de-duplicating them which resulted in us producing `setClassMetadataAsync` calls where the callback can have multiple parameters with the same name. This was a problem both in full and partial compilation, but the latter was more visible, because Babel throws an error in such cases.
These changes add some logic to de-duplicate the dependencies so that we produce valid code.
Fixes#59922.
PR Close#59926
When we generate an HMR replacement function, we determine which locals from the file are used and we pass them by reference. This works fine in most cases, but breaks down for const enums which don't have a runtime representation.
These changes work around the issue by passing in all the values as an object literal.
Fixes#59800.
PR Close#59815
Fixes that we were filtering out the component itself from the set of dependencies when HMR is enabled, breaking self-referencing components.
Fixes#59632.
PR Close#59644
When HMR is enabled, we need to capture the dependencies used in a template and forward them to the HMR replacement function. One half of this process is static, meaning that we can't change it after the initial compilation. Tree shaking becomes a problem in such a case, because the user can change the template in a way that changes the set of dependencies which will start matching with the static part of the HMR code.
These changes disable the tree shaking when HMR is enabled to ensure that the dependencies stay stable.
Fixes#59581.
PR Close#59595
Fixes that the compiler wasn't capturing defer block dependencies correctly when `supportTestBed` is disabled. We had tests for this, but we didn't notice the issue because the dependencies ended up being captured because of the `setClassMetadata` calls. Once they're disabled, the dependencies stopped being recorded.
Fixes#59310.
PR Close#59313
Currently host bindings are in a bit of a weird state, because their source spans all point to the root object literal, rather than the individual expression. This is tricky to handle at the moment, because the object is being passed around as a `Record<string, string>` since the compiler needs to support both JIT and non-JIT environments, and because the AOT compiler evaluates the entire literal rather than doing it expression-by-expression. As a result, when we report errors in one of the host bindings, we end up highlighting the entire expression which can be very noisy in an IDE.
These changes aim to report a more accurate error for the most common case where the `host` object is initialized to a `string -> string` object literal by matching the failing expression to one of the property initializers. Note that this isn't 100% reliable, because we can't map cases like `host: SOME_CONST`, but it's still better than the current setup.
PR Close#58870
This fixes an issue where the lazy-routes migration would crash for component classes a
decorator without arguments in front of the `@Component` decorator (in particular, it needed
to be the first decorator).
Fixes#58793
PR Close#58796
Currently when application source code references e.g. an NgModule that
points to references that aren't available, the compiler will break at
runtime without any actionable/reasonable error.
This could happen for example when a library is referenced in code, but
the library is simply not available in the `node_modules`. Clearly,
TypeScript would issue import diagnostics here, but the Angular compiler
shouldn't break fatally. This is useful for migrations which may run
against projects which aren't fully compilable. The compiler handles
this fine in all cases, except when processing `.d.ts` currently... and
the runtime exception invalides all other information of the program
etc.
This commit fixes this by degrading such unexpected cases for `.d.ts`
metadata reading to be handled gracefully. This matches existing logic
where the `.d.ts` doesn't necessarily match the "expecation"/"expected
format".
The worst case is that the Angular compiler will not have type
information for some directives of e.g. a library that just isn't
installed in local `node_modules`; compared to magical errors and
unexpected runtime behavior.
PR Close#58515
Disables the standalone by default behavior in the compiler when running against and older version of Angular. This is necessary, because the language service may be using the latest version of the compiler against and older version of core in a particular workspace.
PR Close#58405
