Prior to this commit, we had two different modes for change detection
execution for Ivy, depending on whether you called `bootstrap()` or
`renderComponent()`. In the former case, we would complete creation
mode for all components in the tree before beginning update mode for
any component. In the latter case, we would run creation mode and
update mode together for each component individually.
Maintaining code to support these two different execution orders was
unnecessarily complex, so this commit aligns the two bootstrapping
mechanisms to execute in the same order. Now creation mode always
runs for all components before update mode begins.
This change also simplifies our rendering logic so that we use
`LView` flags as the source of truth for rendering mode instead of
`rf` function arguments. This fixed some related bugs (e.g. calling
`ViewRef.detectChanges` synchronously after the view's creation
would create view nodes twice, view queries would execute twice, etc).
PR Close#27744
This option means guards and resolvers will ignore changes when a provided predicate function returns `false`. This supports use cases where an application needs to ignore some param updates but not others. For example, changing a sort param in the URL might need to be ignored, whereas changing the a `project` param might require re-run of guards and resolvers.
Related to #26861#18253#27464
PR Close#27682
Typescript 3.2 introduced BigInt type, and consequently the
implementation for checkExpressionWorker() in checkers.ts is refactored.
For NumberLiteral and StringLiteral types, 'text' filed must be present
in the Node type, therefore they must be LiteralLikeNode instead of
Node.
PR Close#27536
* We should try loading Angular.JS for the upgrade tests in their minfied output. There seems to be a lot flakiness in regards to loading `AngularJS` within Travis, and the `onerror` messages aren't really too helpful. In order to reduce the payload that will be passed through the Saucelabs tunnel, we should try to load the minfied output files.
PR Close#27711
This commit fixes a bug whereby the path of the entry_module is not
consistent with the workspace name, which does not permit dashes
in the name.
PR Close#27719
It looks like `fixmeIvy` imports were accidentally removed from Router integration tests, thus causing build errors. The necessary imports are now restored and the project should build normally.
PR Close#27720
We invoked `hostBindings` function in Create and Update modes with different element index due to the fact that we did not subtract HEADER_OFFSET from the index before passing it to `hostBindings` function in Create mode. Now we subtract HEADER_OFFSET value before invoking `hostBindings`, which makes Ceate and Update calls consistent.
PR Close#27694
Context discovery was only available on elements. This PR adds support for containers and ICU expressions.
FW-378 #resolve
FW-665 #comment linker integration tests
PR Close#27644
Currently whenever the upgrade test helper fails to load a given AngularJS version, the error that will be rejected is technically not an error because the `onerror` callback is not returning an error, but an "ErrorEvent".
Since that `ErrorEvent` is basically just rejected, browsers will print
the error as followed:
```
Failed: [object Event]
```
This is not helpful at all and also implies that there _might_ be more
information hidden within the `Event` instance. Unfortunately that's not
the case (at least on browsers we test against) and the logic to extract
the data from the event would be not worth the effort, we just return a
simple custom `Error` that won't imply that there is more information
hidden.
PR Close#27706
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360
With that fixed, `ng test` now works.
`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.
PR Close#27715
In ngUpgrade (dynamic) we create a dynamic Angular `Directive` that wraps AngularJS components
that are being upgraded. The constructor of this `Directive` class returns a different instance
than `this`. It is this instance that actually contains the life-cycle hook handlers.
This would break in ivy, since the methods on the prototype of the original class are wired up,
rather than the instance methods. This results in hooks like `ngOnInit` not being called.
This commit refactors the code to extend the inner class that was being returned so that the
prototype chain is correct for both ViewEngine and ivy.
This change resolves a number of failing ivy tests, but also exposes other failures that were
masked by this issue. The tests have been updated accordingly.
(FW-812)
PR Close#27660
`NgModule` requires that `Component`s/`Directive`s/`Pipe`s are listed in
declarations, and that each `Component`s/`Directive`s/`Pipe` is declared
in exactly one `NgModule`. This change adds runtime checks to ensure
that these sementics are true at runtime.
There will need to be seperate set of checks for the AoT path of the
codebase to verify that same set of semantics hold. Due to current
design there does not seem to be an easy way to share the two checks
because JIT deal with references where as AoT deals with AST nodes.
PR Close#27604
With the bundle info being assembled into a single object before the
transform is started, we now greedily create a TypeScript program up-front.
If a marker file exists that indicates that the bundle could be skipped
the program creation has already taken place which takes a significant
amount of time. This commit moves the marker check to occur before the
bundle is assembled.
PR Close#27438
ngcc would feed ngtsc with the function declaration inside of an IIFE as
that is considered the class symbol's declaration node, according to
TypeScript's `ts.Symbol.valueDeclaration`. ngtsc however only considered
variable decls and actual class decls as potential class declarations,
so given the function declaration node it would fail to generate the
`setClassMetadata` call.
ngtsc no longer makes its own assumptions about what classes look like,
but always asks the reflection host to yield this kind of information.
PR Close#27438
While creating FESM files, rollup usually drops all unused symbols.
All *__POST_R3__ are unused unless ngcc rewires stuff. To prevent this DCE
we reexport them as private symbols. If ngcc is not used, these symbols will
be dropped when we optimize an application bundle.
PR Close#27438
Prior to this change, we were unable to match directives using `ng-template` tags (for example the following selector would not work even though there might be some <ng-template>s in a template: `ng-template[directiveA]`. As a result, that broke some components that relies on such selectors to work. In order to resolve the problem, we now pass tag name to the `template` instruction (where we passed `null` before) and this tag name is used for matching at runtime. This update should also help support projecting containers, because the tag name is required to properly match such elements.
PR Close#27636
A surprising interaction with the MagicString library caused inserted
Ivy definitions to be dropped during the removal of decorators, iff all
decorators on the class could be removed. In that case, the removal
location corresponds with the exact location where Ivy definitions were
inserted into.
This commit moves the removal of decorators to occur before Ivy
definitions are inserted. This effectively avoids the problem, as later
inserted text fragments will be retained by MagicString.
PR Close#27159
All the tests in `packages/core/test/view/` are specific to the `ViewEngine` and shouldn't run for ivy. This PR introduces a new BUILD.bazel file to run those tests separately.
PR Close#27645
If a template contains specific TypeScript syntax, such as a non-null
assertion, the code that is emitted from ngcc into a JavaScript bundle
should not retain such syntax as it is invalid in JS.
A full-blown TypeScript emit of a complete ts.SourceFile would be
required to be able to emit JS and possibly downlevel into a lower
language target, which is not an option for ngcc as it currently
operates on partial ASTs, not full source files.
Instead, ngtsc no longer produces TypeScript specific syntax in the first
place, such that TypeScript print logic will only generate JS code.
PR Close#27051
The default 10 items are often not enough to debug deeply nested compilation operations.
This PR is based on @martinprobst's http://cl/225528216.
PR Close#27678
In Ivy, a pure call to `setClassMetadata` is inserted to retain the
information that would otherwise be lost while eliding the Angular
decorators. In the past, the Angular constructor decorators were
wrapped inside of an anonymous function which was only evaluated once
`ReflectionCapabilities` was requested for such metadata. This approach
prevents forward references from inside the constructor parameter
decorators from being evaluated before they are available.
In the `setClassMetadata` call, the constructor parameters were not wrapped
within an anonymous function, such that forward references were evaluated
too early, causing runtime errors.
This commit changes the `setClassMetadata` call to pass the constructor
parameter decorators inside of an anonymous function again, such that
forward references are not resolved until requested by
`ReflectionCapabilities`, therefore avoiding the early reads of forward refs.
PR Close#27561
With ngcc's ability to fixup pre-Ivy ModuleWithProviders such that they
include a reference to the NgModule type, the type may become a qualified
name:
```
import {ModuleWithProviders} from '@angular/core';
import * as ngcc0 from './module';
export declare provide(): ModuleWithProviders<ngcc0.Module>;
```
ngtsc now takes this situation into account when reflecting a
ModuleWithProvider's type argument.
PR Close#27562
Currently the `ViewRef.destroy` method assumes that its index inside the view container will always be valid, however if it has been removed already, it'll be -1 which will throw an error.
The error manifested itself in one of the unit tests where a view had been detached during the test and then `TestBed` attempted to destroy its `ComponentRef` which ended threw an `Error during cleanup of component`.
PR Close#27585
Navigating to a route such as `/users`, you may get redirected to `/login`. Previously, if you go then route to `/users` again the URL will end up showing `/users` after the second redirect. This only happened in `UrlUpdateStrategy="eager"`. This is now fixed so after the second redirect, the URL shows the correct page.
Fixes#27116
PR Close#27523
Closure Compiler doesn't allow non-goo.getMsg const names to start with `MSG_`, so we should use different prefix for const that references a result of the `i18nPostprocess` fn invocation. With this update we also append file-based prefix to i18n constants (via $$ postfix) to ensure the names are unique across codebase of a project (otherwise it might lead to errors while compiling a project with Closure Compiler).
PR Close#27468
In order to keep the bazel bin directory as clean as possible, we should not write definition files that are not relevant to a `ng_package` to an undesired location in the bazel bin directory. This currently just happens because we only filter out external definition files while we also should filter out definitions that aren't just in the current package.
The `packager.ts` file currently tries to write these files to the package, but fails because those are not inside of the current package. So the logic to create a relative path for the file fails, and the definition will be copied to a location like:
```js
// Notice the double "bazel-out" here.
C:\Users\Paul\_bazel_Paul\kn4tsvyh\execroot\angular_material\bazel-out\x64_windows-fastbuild\bin\src\bazel-out\x64_windows-fastbuild\bin\src\cdk
```
[See logic that causes this](4f9374951d/packages/bazel/src/ng_package/packager.ts (L105-L124)) (nothing wrong with that logic because it assumes that only paths from within the package are passed to it)
PR Close#27519
ngtsc now produces flat module index files when that option is enabled
in tsconfig, but Bazel still needs the output declared in order for them to
be passed through.
This fixes some tests which verify this behavior on Bazel.
FW-738 #resolve
PR Close#27655
Since Renderer is shared across root and child views, we need to avoid `destroy` method invocation for child views and only invoke is for root view when needed. Prior to this change, the `destroy` function was called whenever child view was destroyed, thus causing errors at runtime.
PR Close#27592
The pure functions in host bindings change was merged after the change in
host binding instructions, so it had a new test that wasn't yet updated
with the new generated code. This commit updates the new test.
PR Close#27605
Previously in Ivy, host bindings did not work if they shared a public name
with an Input because they used the `elementProperty` instruction as is.
This instruction was originally built for inside component templates, so it
would either set a directive input OR a native property. This is the
correct behavior for inside a template, but for host bindings, we always
want the native properties to be set regardless of the presence of an Input.
This change adds an extra argument to `elementProperty` so we can tell it to
ignore directive inputs and only set native properties (if it is in the
context of a host binding).
PR Close#27589
Prior to this update, we always returned the number of host vars defined in @Component definition as a value for `allocatePureFunctionsSlot` callback in ValueConverter. As a result, pure function arguments were not accounted for, thus leasing to incorrect slot offsets in `pureFunction` calls. Now we update and return total # of host vars, so the offsets are defined correctly.
PR Close#27587
When @angular/bazel is installed, a postinstall script is run to make sure that
the npm version is *exactly* the same as the Angular repository install by
Bazel. This check is overly stringent. Instead, it should enforce that the
version satisfies the range check instead. This is consistent with the range
defined in angular-cli/packages/schematics/angular/utility/latest-versions.ts.
This commit also fixes the Bazel workspace to use the same Rxjs version if it's
already installed.
PR Close#27526
This release of rules_typescript fixes a critical bug: typescript code
was not checked at all, including type-checking, tsetse, and strict deps
fixes#27569
PR Close#27586
In `ViewRef.detectChanges`, we are passing `ViewRef.context` into `detectChanges` to trigger change detection. This only makes sense for component `ViewRefs` (i.e. injected `ChangeDetectorRefs`) because with embedded views, `context` is not a component instance where the view has been monkey-patched. It's a just a normal object, so the view will be undefined.
In order to resolve this problem, we now invoke `detectChangesInternal` and also pass `LView` (to make sure we always have a view available).
PR Close#27521
We had two `NodeInjector` classes: one in `view_compatibility` and one in `di`. We replaced the one in `di` with the one from `view_compatibility` and reconciled their differences.
PR Close#27541
`@angular/bazel` currently requires TypeScript 3.1.x as a peer dependency, but comes with `tsickle` as dependency. The current version of `tsickle` that is specified by `@angular/bazel` does not support TypeScript 3.1.x (which is a peer dependency) and therefore we need to make sure that `tsickle` works with the required TypeScript versions.
This change updates `tsickle` to the latest version that comes with b10fb6de0a in order to work with TypeScript 3.1.x.
PR Close#27402
Switch from Skylint to buildifier --lint - this is required for the Bazel 0.20 upgrade since Bazel no longer lets us use the embedded JDK to build and run Java programs, and Skylint is a Java program
PR Close#27489
Prior to this change, animation event names were treated as a regular event names, stripping `@` symbol and event phase. As a result, event listeners were not invoked during animations. Now animation event name is formatted as needed and the necessary callbacks are invoked.
PR Close#27525
Previously, ngtsc did not respect the angularCompilerOptions settings
for generating flat module indices. This commit adds a
FlatIndexGenerator which is used to implement those options.
FW-738 #resolve
PR Close#27497
Previously the ngtsc ShimGenerator interface expected that all shims would
be generated using the contents of existing ts.SourceFiles. This assumption
was true for ngfactory and ngsummary files, but breaks down for flat module
index files, which are standalone.
This commit prepares for flat module index generation by enabling shim
generators which don't require an existing file.
PR Close#27497
While generating attributes for `projection` instruction, we checked whether attribute name is equal to 'select' in lower case. However in other cases we treat 'select' attribute name as case-insensitive. This PR makes 'select' attribute consistently case-insensitive.
PR Close#27500
Prior to this change, animation properties were defined as element attributes, which caused errors at runtime. Now all animation-related attributes are defined as element properties.
Also as a part of this update, we start to account for bindings used in animations, which was previously missing.
PR Close#27496
If user has already installed Angular, Bazel should fetch the same
version. Otherwise, user will see an error in the post-install step
that performs version check.
PR Close#27495
Analogously to directives, the `ngInjectableDef` field in .d.ts files is
annotated with the type of service that it represents. If the service
contains required generic type arguments, these must be included in
the .d.ts file.
PR Close#27037
Common insensitive platforms are `win32/win64` (see:
[here](3e4c5c95ab/src/compiler/sys.ts (L681-L682)))
Currently when running `bazel build packages/core --define=compile=aot`, the `compiler-cli` will throw because it cannot find the `index.ngfactory.ts` file in the compiler host. This is because the shim host wrapper is not properly generating the requested `ngfactory` file.
This happens because we call `getCanonicalFileName` that returns a path that is different to the actual program filenames that are used to construct a map of generated files. Since the generators always use the paths which are not "canonical" and pases them internally like that, we can just stop manually calling `getCanonicalFileName`.
PR Close#27466
Some "platform-browser" tests were updated before `fixmeIvy` function contract was changed to `fixmeIvy(...).it(...)`, thus triggering failed tests to run on CI. This commit updates these cases to invoke `fixmeIvy` correctly.
PR Close#27498
This commit enables the above test to run under --define=compile=aot.
To accomplish this, one import is rewritten from a strange form to the
correct absolute form.
FW-658 #resolve
PR Close#27483
Previously, Bazel/Blaze were only expecting .ngfactory.js and .ngsummary.js
files to be generated in legacy mode. ngtsc was attempting to write those
files, but they ended up being ignored at the Bazel level.
This commit causes Bazel to expect these files, and rearranges the logic
a little bit as the name 'include_ng_files' is now incorrect.
FW-514 FW-737 #resolve
PR Close#27483
ngfactory files have a ɵNonEmptyModule constant included if there are no
other exported factory symbols. Previously this extra export was added
dynamically in a TS transformer.
However, synthetically constructed exports don't get properly downleveled
during JS emit, and this generated constant caused issues with downstream
tests.
Instead, this commit configures the shim to always have this export to
begin with, and to filter it out if it's not required.
Testing strategy: covered by existing ngtsc_spec tests which verify the
presence of the ɵNonEmptyModule symbol.
PR Close#27483
In ngtsc, files loaded into the ts.Program have a "module name", set via
ts.SourceFile.moduleName, which ends up being written into an AMD module
name triple-slash directive in the generated .js file.
For generated shim files (ngfactories, ngsummaries) that are constructed
synthetically, there was previously no moduleName set, which caused some
issues with downstream tests.
This commit adds logic to compute and set moduleNames for both generated
ngfactory and ngsummary shims.
PR Close#27483
A previous fix to ngtsc opened the door for duplicate directives in
the 'directives' array of a component. This would happen if the directive
was declared in a module which was imported more than once within the
component's module.
This commit adds deduplication when the component's scope is materialized,
so declarations which arrive via more than one module import are coalesced.
PR Close#27462
This commit allows //packages/bazel/test/ngc-wrapped/... tests to run
under Ivy mode. To get them to pass, it addresses a problem with the
way the tests are configured: both test targets have sloppy .d.ts
dependencies configured, leading to many type errors being generated
in TypeScript for the .d.ts files.
Due to the way ngc directs TypeScript emit, it avoids type-checking
.d.ts files and thus this issue does not surface. ngtsc does a whole-
program emit which results in full .d.ts type-checking by default,
catching this configuration issue.
To fix this, skipLibCheck is added to the tsconfig.jsons for these
tests, which tells TypeScript to skip type-checking of the .d.ts files,
avoiding this problem in a similar way to ngc.
PR Close#27470
The method `ts.CompilerHost.directoryExists` is optional, and was not
previously handled by our ts.CompilerHost wrapper for factory and
summary shims (GeneratedShimsHostWrapper).
TypeScript checks for the existence of this method and silently ignores
things like typeRoots if it's not found. This commit adds proper handling
of directoryExists() to the shim.
A test is also added which verifies typeRoots behavior works when shims
are enabled.
PR Close#27470
Previously the ngfactory shim generator in ngtsc would always write two
imports in the factory file shims:
1) an import to @angular/core
2) an import to the base file
If the base file has no exports, import #2 would be empty. This turns out
to cause issues downstream.
This commit changes the generated shim so if there are no exports in the
base file, the generated shim is empty too.
PR Close#27470
This option means guards and resolvers will ignore changes to matrix parameters. Guards and resolvers will be rerun when the path changes, when path parameters change, or when query parameters change.
The primary use case for such a mode is when updating the UI and getting the URL to be in sync with local changes. For example, if displaying a sortable table, changing the sort direction is often handled by the table itself. But you would want to update the URL to be in sync with what's being displayed to the user. As long as the table sort direction is stored as a matrix parameter, you can use this option to update the URL without causing the overhead of re-running guards and resolvers.
Related to #26861#18253
PR Close#27464
PR #27404 introduced additional test case to make sure we generate `elementStyling` instructions with proper set of arguments (first argument was missing in some cases). It looks like that PR was created before we updated host vars count calculation and the `allocHostVars` becomes unnecessary in the test cases introduced in PR #27404. This commit actualizes this test to get rid of unnecessary `allocHostVars` instruction.
PR Close#27473
(FW-777)
When an Injector is provided, R3Injector instantiates it by calling its
constructor instead of its factory, not resolving dependencies.
With this fix, the ngInjectorDef is checked and the factory is correctly
used if it is found.
PR Close#27456
Previously, if the two injectors are not the same, jasmine tried to
display an error message, but it got stuck in an infinite loop trying
to render the injectors that were different.
PR Close#27454
When detaching a view by its index via `ViewContainerRef.detach(index)`, in `ViewEngine` we used to return a new `ViewRef` ([for reference](https://github.com/angular/angular/blob/master/packages/core/src/view/refs.ts#L227)), however in Ivy we return the same `ViewRef` which means that its internal `_viewContainerRef` is never reset and we'll throw an error if the consumer tried to attach it to the `ApplicationRef`. These changes return a new `ViewRef` in order to match the original behavior.
These changes also add the same errors as `ViewEngine` when attempting to attach a view that is attached already. This was the original goal of this PR, however it ended up uncovering the issues with the `ViewRef`.
PR Close#27437
The logic that generates first argument for the `elementStyling` instruction was missing the check that directive expression is specified. As a result, in some cases first argument was not added, thus making function invocation incorrect. Now the presence of directive expression is taken into account and the `null` expression is generated as needed.
PR Close#27404
In some applications, developers define a `ts_library` that just consists of `d.ts` files (e.g. to type `module.id`; see: https://github.com/angular/material2/blob/master/src/module-typings.d.ts), and expect the `esm5.bzl` file to not throw an error like:
```
target.typescript.replay_params.outputs
struct' object has no attribute 'outputs'
```
The "replay_parameters" property will exist in that case, but is set to "None" because there is no action that should be replayed in favor of producing ES5 outputs. See: https://github.com/bazelbuild/rules_typescript/pull/326. Notice that this right now breaks similarly because an empty `struct()` is returned that does not have a property called `outputs`. [#326](https://github.com/bazelbuild/rules_typescript/pull/326) fixes that by being explicit that there is no _action_ at all.
PR Close#27401
Prior to this change `projectDef` instructions were placed to root templates only, thus the necessary information (selectors) in nested templates was missing. This update adds the logic to insert `projectDef` instructions to all templates where <ng-content> is present.
PR Close#27384
Previously ngtsc assumed resource files (templateUrl, styleUrls) would be
physically present in the file system relative to the .ts file which
referenced them. However, ngc previously resolved such references in the
context of ts.CompilerOptions.rootDirs. Material depends on this
functionality in its build.
This commit introduces resolution of resources by leveraging the TypeScript
module resolver, ts.resolveModuleName(). This resolver is used in a way
which will never succeed, but on failure will return a list of locations
checked. This list is then filtered to obtain the correct potential
locations of the resource.
PR Close#27357
This commit adds support for resolution of styleUrls to ngtsc. Previously
this field was never read, and so components with styleUrls would appear
unstyled after compilation.
PR Close#27357
When a single resource is preloaded twice in ngtsc, the second request
would be recognized as in-flight in which case `undefined` would
be returned, which signals to the compilation that is can resume
synchronously. The compilation would then proceed immediately and call
`load`, only to find out that the request is still in-flight which is
not allowed.
This commit caches the Promise of the in-flight fetch requests, such
that subsequent preload requests can return the corresponding Promise
instance.
PR Close#27357
* Currently when building a `ng_module` with Bazel and having the flat module id option set, the flat module files are not being generated because `@angular/compiler-cli` does not properly determine the entry-point file.
Note that this logic is not necessarily specific to Bazel and the same problem can happen without Bazel if multiple TypeScript input files are specified while the `flatModuleIndex` option has been enabled.
PR Close#27200
Currently when building the `ng_package` multiple times, the old `ng_package` output will be copied over to the new `ng_package` content. Resulting in packages like `src/cdk/npm_package/npm_package/npm_package/AND_MORE`.
This happens because currently all TypeScript definition files are resolved from within the `binDir`. This is just wrong because it could then take up the `d.ts` files from the previous `ng_package` output. All typescript definitions that belong to the target package, should be resolved through Bazel and copied based on that computation.
Also fixes that `esm` files aren't written to the `ng_package` on Windows. This is because we try to flatten paths using the `path.delimiter` while the path is always using Posix delimiters (causing the paths to be incorrect)
PR Close#27200
* Currently when building the ES5 and ES2015 output, `ngc_wrapped` will fail because it tries to write the `fs.openSync` the tsickle output file at the same time. This causes a runtime exception in Windows and can be fixed by just writing the externs for ES5 mode to the proper ES5 "output root".
PR Close#27200
* Fixes that `ng_package` does not work generate UMD bundles on Windows because the `esm5/` files are not written to the output directory. This is because `rootDirs` and `rootDir` are posix paths and cause invalid relative paths when mixed with Windows backslash paths.
PR Close#27200
For ngcc's processing of ES5 bundles, the spread syntax has been
downleveled from `[...ARRAY]` to become `ARRAY.slice()`. This commit
adds basic support for static resolution of such call.
PR Close#27158
Prior to this change, the number of host vars stored for directives with `hostBindings` in expando block was incorrect for inherited directives (in case both parent and child directive have `hostBindings` defined). Now if we identify that we already added a `hostBinding` into expando block, we just increase the corresponding number of host binding vars
PR Close#27392
Also build releases into a dedicated output_base so you can't
accidentally publish with outdated version stamp.
Bump the version of rules_nodejs so we don't need to create the
symlink_prefixes for the .publish command to work.
PR Close#27362
The problem was caused by missing `allocateBindingSlots` that led to incorrect # of vars defined for components and as a result, causing errors at runtime. Now all `bind` operation are accounted for and the number of `vars` is correct.
PR Close#27338
The problem was caused by the self-closing i18n instruction that was generated in case we have styling instructions defined for a component. As a result, that caused problems at runtime. This update adds extra check to avoid creating self-closing i18n instructions (create i18nStart and i18nEnd instructions instead) when styling instructions are present.
PR Close#27330
Ngcc will now render additional exports for classes that are referenced in
`NgModule` decorated classes, but which were not publicly exported
from an entry-point of the package.
This is important because when ngtsc compiles libraries processed by ngcc
it needs to be able to publcly access decorated classes that are referenced
by `NgModule` decorated classes in order to build templates that use these
classes.
Doing this re-exporting is not without its risks. There are chances that
the class is not exported correctly: there may already be similarly named
exports from the entry-point or the class may be being aliased. But there
is not much more we can do from the point of view of ngcc to workaround
such scenarios. Generally, packages should have been built so that this
approach works.
PR Close#26906
There are a number of variables that need to be passed around
the program, in particular to the renderers, which benefit from being
stored in well defined objects.
The new `EntryPointBundle` structure is a specific format of an entry-point
and contains the compiled `BundleProgram` objects for the source and typings,
if appropriate.
This change helps with future refactoring, where we may need to add new
properties to this object. It allows us to maintain more stable APIs between
the constituent parts of ngcc, rather than passing lots of primitive values
around throughout the program.
PR Close#26906
The `NgModuleDecoratorHandler` can now register all the references that
it finds in the `NgModule` metadata, such as `declarations`, `imports`,
`exports` etc.
This information can then be used by ngcc to work out if any of these
references are internal only and need to be manually exported from a
library's entry-point.
PR Close#26906
By inverting the relationship between `EntryPointPaths` and
`EntryPointFormat` we can have interfaces rather than types.
Thanks to @gkalpak for this idea.
PR Close#26906
If a decorated class is not publicly exported via an entry-point then the
previous approach to finding the associated typings file failed.
Now we ensure that we extract all the class declarations from the
dtsTypings program, even if they are not exported from the entry-point.
This is achieved by also parsing statements of each source file, rather
than just parsing classes that are exported from the entry-point.
Because we now look at all the files, it is possible for there to be multiple
class declarations with the same local name. In this case, only the first
declaration with a given name is added to the map; subsequent classes are
ignored.
We are most interested in classes that are publicly exported from the
entry-point, so these are added to the map first, to ensure that they are
not ignored.
PR Close#26906
In Angular, it used to be an accepted practice to use strings as dependency
injection tokens. E.g. {provide: 'test', useValue: 'provided'}. However,
the Ivy node injection system did not support this. The Ivy DI system
attempts to patch a Bloom bit index onto each type registered with it, and
this patch operation does not work for a string token.
This commit adds string token support to the bloom filter system by
reserving bit 0 for string tokens. This eliminates the need for each string
token to store its own Bloom bit, at the expense of slightly more expensive
lookups of string tokens.
PR Close#27383
Having real functions allows me to bypass individual checks, ex.:
```
export function fixmeIvy(reason: string): boolean {
return true;
}
```
This is useful for situation where I want to see if previously disabled tests
were fixed (ex. some PRs merged). In this case I don't want to run tests that
I know are not passing (obsolete / modified).
PR Close#27372
BREAKING CHANGES:
Bazel users: rules_angular_dependencies() will no longer install transitive dependencies of build_bazel_rules_nodejs and build_bazel_rules_typescript. User WORKSPACE files will now need to install rules_nodejs and rules_typescript transitive deps directly:
```
load("@build_bazel_rules_typescript//:package.bzl", "rules_typescript_dependencies")
rules_typescript_dependencies()
load("@build_bazel_rules_nodejs//:package.bzl", "rules_nodejs_dependencies")
rules_nodejs_dependencies()
```
PR Close#27264
Previously the concept of multiple directives with the same selector was
not supported by ngtsc. This is due to the treatment of directives for a
component as a Map from selector to the directive, which is an erroneous
representation.
Now the directives for a component are stored as an array which supports
multiple directives with the same selector.
Testing strategy: a new ngtsc_spec test asserts that multiple directives
with the same selector are matched on an element.
PR Close#27298
Most of the specs in these tests are not relevant to Ivy:
//packages/compiler/test:test
//packages/compiler/test:test_web_chromium-local
However, a few test pieces of the compiler infrastructure that are used in
Ivy, and new BUILD.bazel files are created to separate them from the above
disabled targets:
//packages/compiler/test/css_parser:css_parser
//packages/compiler/test/css_parser:css_parser_web
//packages/compiler/test/expression_parser:expression_parser
//packages/compiler/test/expression_parser:expression_parser_web
//packages/compiler/test/ml_parser:ml_parser
//packages/compiler/test/ml_parser:ml_parser_web
//packages/compiler/test/selector:selector
//packages/compiler/test/selector:selector_web
PR Close#27301
These tests are not relevant to Ivy:
//packages/compiler-cli/test/diagnostics:check_types
//packages/compiler-cli/test/diagnostics:expression_diagnostics
//packages/compiler-cli/test/transformers:test
//packages/compiler-cli/test:extract_i18n
The //packages/compiler-cli/test:ngtools_api test has 2 specs, one of
which passes and the other of which depends on ngtsc supporting lazy
routes. It's now disabled with fixmeIvy().
PR Close#27301
BREAKING CHANGE:
The public API for `DebugNode` was accidentally too broad. This change removes
1. Public constructor. Since `DebugNode` is a way for Angular to communicate information
on to the developer there is no reason why the developer should ever need to
Instantiate the `DebugNode`
2. We are also removing `removeChild`, `addChild`, `insertBefore`, and `insertChildAfter`.
All of these methods are used by Angular to constructor the correct `DebugNode` tree.
There is no reason why the developer should ever be constructing a `DebugNode` tree
And these methods should have never been made public.
3. All properties have been change to `readonly` since `DebugNode` is used by Angular
to communicate to developer and there is no reason why these APIs should be writable.
While technically breaking change we don’t expect anyone to be effected by this change.
PR Close#27223
This fixes an issue where a value would hide the type.
```
export interface Foo {
someMethod(): void;
}
export const Foo: Function = ...;
```
In the above example the `Foo` constant will hide the `interface Foo` symbol.
This change properly saves the interface in addition to the type.
PR Close#27223
A recent commit (probably 2c7386c) has changed the import graph of the
DI types in core, and somehow results in the ngc compiler deciding to
re-export core DI types from application factories which tangentially
use inject(). This is not really surprising; ngc's import graph can be
very unstable.
However, this results in a re-export of InjectFlags surviving JS
compilation. InjectFlags was a const enum, akin to an interface in TS,
with no runtime repesentation. This causes a warning to be emitted by
Webpack when it sees the re-export of InjectFlags.
This commit avoids the issue by removing 'const' from the declaration
of InjectFlags, causing it to have a runtime value. This is a temporary
fix. The real fix will be for ngc to no longer write exports of const
enums.
Testing strategy: manually verified. Due to the problem only manifesting
when recompiling after a change and then running Webpack, there is no
existing framework via which this could be easily tested with an
integration test. Additionally, the potential for this issue is gone in
Ivy, so this solution is only temporarily needed.
Fixes#27251.
PR Close#27279
These paths are no longer needed / used.
I had to disable one jit mode spec because it fails now that we actually run it.
I root caused the jit test failure as missing forwardRef support. See FW-645.
PR Close#27278
Currently we store the `_appRef` when a `ViewRef` is attached, however we don't use it for anything. These changes use it to detach the view from the `ApplicationRef` when it is destroyed. These changes also fix that the `ComponentRef` doesn't remove its `ViewRef` on destroy.
PR Close#27276
The way that `UpgradeAdapter` needs to be setup, you often find that
you must pass a `forwardRef` for an `NgModule.import`. Pre-ivy, this
gets resolved at runtime, but until this is implemented in ivy, we can
workaround it by resolving it in the `UpgradeAdapter` upfront.
This should be backward-compatible since by the time we actually
create the dynamic `NgModule` that has the import, the imported
class should be defined.
PR Close#27132
When ngtsc compiles @angular/core, it rewrites core imports to the
r3_symbols.ts file that exposes all internal symbols under their
external name. When creating the FESM bundle, the r3_symbols.ts file
causes the external symbol names to be rewritten to their internal name.
Under ngcc compilations of FESM bundles, the indirection of
r3_symbols.ts is no longer in place such that the external names are
retained in the bundle. Previously, the external name `ɵdefineNgModule`
was explicitly declared internally to resolve this issue, but the
recently added `setClassMetadata` was not declared as such, causing
runtime errors.
Instead of relying on the r3_symbols.ts file to perform the rewrite of
the external modules to their internal variants, the translation is
moved into the `ImportManager` during the compilation itself. This
avoids the need for providing the external name manually.
PR Close#27055
Some engineers were already on Yarn 0.10.x which was permitted by the range in our package.json#engines
However this introduced 'integrity sha512' lines into the yarn.lock files.
Then when engineers use yarn 0.9 (in particular, Bazel did this) then the lock files get tons of meaningless edits.
We could force everyone back to yarn 0.9 but this commit chooses to instead advance everyone past 0.10
PR Close#27193
Now that the Ivy switch transform uses ts.getMutableClone() to copy
statements, there's no need to set .parent pointers on the resulting
updated nodes. Doing this was causing assertion failures deep in
TypeScript in some cases.
PR Close#27170
Currently the `useJit` option from `TestBed.configureCompiler` isn't supported. These changes rework the existing test suites not to pass in `useJit` when running with Ivy.
PR Close#27067
This option means guards and resolvers will ignore changes to optional
parameters such as query and matrix params. When the path or any path
params change, guards and resolvers will be run
Related to discussion in #18253
FW-560 #resolve
PR Close#26861
Make a copy of the ts.SourceFile before modifying it in the ivy_switch
transform. It's suspected that the Bazel tsc_wrapped host's SourceFile
cache has issues when the ts.SourceFiles are mutated.
PR Close#27032
In a more specific scenario: Considering people use a custom TypeScript compiler host with `NGC`, they _could_ expect only posix paths in methods like `writeFile`. This at first glance sounds like a trivial issue that should be just fixed by the actual compiler host, but usually TypeScript internal API's just pass around posix normalized paths, and therefore it would be good to follow the same standards when passing JSON genfiles to the `CompilerHost`.
For normal TypeScript files (and TS genfiles), this is already consistent because those will be handled by the actual TypeScript `Program` (see `emitCallback`).
PR Close#27062
Adds support for the `providers` that are passed in through `TestBed.configureCompiler` and scopes the error only if the consumer has passed in `useJit`.
PR Close#27066
This fixes an issue where packages would be skipped if they contained
e.g. RxJS 5 style imports such as
```
import { observeOn } from 'rxjs/operators/observeOn';
```
Given that no package.json file can be found at the imported path, the
dependency would be reported missing, causing the package to be skipped.
PR Close#27031
This API is part of our public api surface and needs to be monitored by the public_api_guard.
I also had to go back and mark all of the exported functions with @publicApi jsdoc tag.
PR Close#27008
Make the error messages thrown when instantiating downgraded components,
injectables and modules more descriptive and actionable, also taking
into account incorrect use of the `downgradedModule` field.
PR Close#26217
Currently, calling `downgradeModule()` more than once is not supported.
If one wants to downgrade multiple Angular modules, they can create a
"super-module" that imports all the rest and downgrade that.
This commit adds support for downgrading multiple Angular modules. If
multiple modules are downgraded, then one must explicitly specify the
downgraded module that each downgraded component or injectable belongs
to, when calling `downgradeComponent()` and `downgradeInjectable()`
respectively.
No modification is needed (i.e. there is no need to specify a module for
downgraded components and injectables), if an app is not using
`downgradeModule()` or if there is only one downgraded Angular module.
Fixes#26062
PR Close#26217
Previously the ivy definition calls we going directly after the
class constructor function But this meant that the lifecycle
hooks attached to the prototype were ignored by the ngtsc
compiler.
Now the definitions are written to the end of the IIFE block,
just before the return statement.
Closes#26849
PR Close#26856
- Format JSDoc for notificationClicks
- Add comment on why handleClick does not use hasOwnProperty
- Add additional test that uses handleClick without action
PR Close#25860
- Serialize notification object before using postMessage
- Close notification on click
- Focus browser if it is not already focused on click
PR Close#25860
The previous version did not support the 'notificationclick' event.
Add event handler for the event and provide an observable of
clicked notifications in the SwPush service.
Closes#20956, #22311
PR Close#25860
When compiling the flat-file version of the `@angular/core` we need to be aware
that we cannot rely upon imported names to access the ivy definition functions.
The compiler is already clever enough to use local function calls rather than
trying to add a namespaced import, but there is a problem if the local name of the
function is different to the exported name. This is the case for functions that
are not part of the public API, and so are exported under a barred-O private alias.
In `@angular/core` the only decorations in use are `@NgModule` and `@Injectable`.
There are no directives, components, pipes, etc.
Since `defineInjectable` is part of the public API of `@angular/core`, the compiler
is able to generate code that references the original non-barred-O version of the
function.
But the `defineNgModule` is not part of the public API and so the compiler must
generate code that refers to it by the private barred-O version of the function.
This commit imports and then re-exports this barred-O version of `defineModule` to
ensure that the symbol is available in the local scope of the flat-file versions of
the `@angular/core` library.
PR Close#26403
For each package entry-point there is only one format that
is used to compile the typings files (.d.ts). This will be
either esm2015 or fesm2015 (preferred). So we would not run
any dts processing in the renderer if we are not compiling
the appropriate format.
PR Close#26403
1) The `DecorationAnalyzer now analyzes all source files, rather than just
the entry-point files, which fixes#26183.
2) The `DecoratorAnalyzer` now runs all the `handler.analyze()` calls
across the whole entry-point *before* running `handler.compile()`. This
ensures that dependencies between the decorated classes *within* an
entry-point are known to the handlers when running the compile process.
3) The `Renderer` now does the transformation of the typings (.d.ts) files
which allows us to support packages that only have flat format
entry-points better, and is faster, since we won't parse `.d.ts` files twice.
PR Close#26403
The rendering of typings is not specific to the package
format, so it doesn't make sense to put it in a specific
renderer.
As a result there is no real difference between esm5 and esm2015
renderers, so there is no point in having separate classes.
PR Close#26403
Previously we always used the non-flat format because we thought
that this was the one that would always be available.
It turns out that this is not the case and that only one of the flat and
non-flat formats may be available.
Therefore we should use whichever is available, defaulting to the flat
format if that exists, since that will be faster to parse.
PR Close#26403
Going forward we need to be able to do the same work on both
flat and non-flat module formats (such as computing arity and
transforming .d.ts files)
PR Close#26403
The Material project uses slightly different properties to the
core Angular project for specifying the different format entry-point.
This commit ensures that we map these properties correctly for both
types of project.
PR Close#26403
The `NgModule` handler generates `R3References` for its declarations, imports,
exports, and bootstrap components, based on the relative import path
between the module and the classes it's referring to. This works fine for
compilation of a .ts Program inside ngtsc, but in ngcc the import needed
in the .d.ts file may be very different to the import needed between .js
files (for example, if the .js files are flattened and the .d.ts is not).
This commit introduces a new API in the `ReflectionHost` for extracting the
.d.ts version of a declaration, and makes use of it in the
`NgModuleDecorationHandler` to write a correct expression for the `NgModule`
definition type.
PR Close#26403
This commit causes a call to setClassMetadata() to be emitted for every
type being compiled by ngtsc (every Angular type). With this metadata,
the TestBed should be able to recompile these classes when overriding
decorator information.
Testing strategy: Tests in the previous commit for
generateSetClassMetadataCall() verify that the metadata as generated is
correct. This commit enables the generation for each DecoratorHandler,
and a test is added to ngtsc_spec to verify all decorated types have
metadata generated for them.
PR Close#26860
This commit introduces generateSetClassMetadataCall(), an API in ngtsc
for generating calls to setClassMetadata() for a given declaration. The
reflection API is used to enumerate Angular decorators on the declaration,
which are converted to a format that ReflectionCapabilities can understand.
The reflection metadata is then patched onto the declared type via a call
to setClassMetadata().
This is simply a utility, a future commit invokes this utility for
each DecoratorHandler.
Testing strategy: tests are included which exercise generateSetClassMetadata
in isolation.
PR Close#26860
This commit introduces the setClassMetadata() private function, which
adds metadata to a type in a way that can be accessed via Angular's
ReflectionCapabilities. Currently, it writes to static fields as if
the metadata being added was downleveled from decorators by tsickle.
The plan is for ngtsc to emit code which calls this function, passing
metadata on to the runtime for testing purposes. Calls to this function
would then be tree-shaken away for production bundles.
Testing strategy: proper operation of this function will be an integral
part of TestBed metadata overriding. Angular core tests will fail if this
is broken.
PR Close#26860
Previously, the Directive, Injectable, and Pipe DecoratorHandlers were
directly returning @angular/compiler metadata from their analyze() steps.
This precludes returning any additional information along with that
metadata. This commit introduces a wrapper interface for these handlers,
opening the door for additional information to be returned from analyze().
Testing strategy: this is a refactor commit, existing test coverage is
sufficient.
PR Close#26860
Previously the ReflectionHost API only returned the names of decorators
and not a reference to their TypeScript Identifier. This commit adds
the identifier itself, so that a consumer can write references to the
decorator.
Testing strategy: this commit is trivial, and the functionality will be
exercised by downstream tests.
PR Close#26860
Uglify and other tree-shakers attempt to determine if the invocation
of a function is side-effectful, and remove it if so (and the result
is unused). A /*@__PURE__*/ annotation on the call site can be used
to hint to the optimizer that the invocation has no side effects and
is safe to tree-shake away.
This commit adds a 'pure' flag to the output AST function call node,
which can be used to signal to downstream emitters that a pure
annotation should be added. It also modifies ngtsc's emitter to
emit an Uglify pure annotation when this flag is set.
Testing strategy: this will be tested via its consumers, by asserting
that pure functions are translated with the correct comment.
PR Close#26860
* Removed `andObservable` helper function in favor of inline implementation
* Flow `boolean | UrlTree` through guards check
* Add tests to verify behavior of `checkGuards` function flowing `UrlTree` properly
PR Close#26521
* No longer depends on a custom CircleCI docker image that comes with Bazel pre-installed. Since Bazel is now available through NPM, we should be able to use the version from `@bazel/bazel` in order to enforce a consistent environment on CI and locally.
* This also reduces the amount of packages that need to be published (ngcontainer is removed)
PR Close#26691
This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies.
It's important because downstream angular/bazel users will observe the same install time.
PR Close#26691
Previously errors in the summary file would include absolute file names.
This is undesirable as the output of a build should not depend on the
current working directory. Doing so causes nondeterminism issues in
builds.
PR Close#26759
These tests were previously not running on CI so they have always been broken,
or got broken just recently :-(.
test(ivy): mark failing test targets with fixme-ivy-jit and fixme-ivy-local tags
PR Close#26735
Comment nodes that are child nodes of unsafe elements are identified as text nodes. This results in the comment node being returned as an encoded string.
Add a check to ignore such comment nodes.
PR Close#25879
We are close enough to blacklist a few test targets, rather than whitelist targets to run...
Because bazel rules can be composed of other rules that don't inherit tags automatically,
I had to explicitly mark all of our ts_library and ng_module targes with "ivy-local" and
"ivy-jit" tags so that we can create a query that excludes all fixme- tagged targets even
if those targets are composed of other targets that don't inherit this tag.
This is the updated overview of ivy related bazel tags:
- ivy-only: target that builds or runs only under ivy
- fixme-ivy-jit: target that doesn't yet build or run under ivy with --compile=jit
- fixme-ivy-local: target that doesn't yet build or run under ivy with --compile=local
- no-ivy-jit: target that is not intended to build or run under ivy with --compile=jit
- no-ivy-local: target that is not intended to build or run under ivy with --compile=local
PR Close#26471
This lets Angular Bazel users install our transitive deps, rather than have to list them in their WORKSPACE file.
If they want a different version of one of these deps, they just need to install it before calling rules_angular_dependencies.
PR Close#26488
This commit adds generation of .ngsummary.js shims alongside .ngfactory.js
shims when generated files are enabled.
Generated .ngsummary shims contain a single, null export for every exported
class with decorators that exists in the original source files. Ivy code
does not depend on summaries, so these exist only as a placeholder to allow
them to be imported and their values passed to old APIs. This preserves
backwards compatibility.
Testing strategy: this commit adds a compiler test to verify the correct
shape and contents of the generated .ngsummary.js files.
PR Close#26495
This commit refactors the shim host to be agnostic to the shims being
generated, and provides an API for generating additional shims besides
the .ngfactory.js. This will be used in a following commit to generate
.ngsummary.js shims.
Testing strategy: this refactor introduces no new behavior, so it's
sufficient that the existing tests for factory shim generation continue
to pass.
PR Close#26495
This simple refactor of the build rules renames the .ngfactory.js shim
generator to 'shims' instead of 'factories', in preparation for adding
.ngsummary.js shim generation.
Testing strategy: this commit does not introduce any new behavior and
merely moves files and symbols around. It's sufficient that the existing
ngtsc tests pass.
PR Close#26495
Originally, the ivy_switch mechanism used Bazel genrules to conditionally
compile one TS file or another depending on whether ngc or ngtsc was the
selected compiler. This was done because we wanted to avoid importing
certain modules (and thus pulling them into the build) if Ivy was on or
off. This mechanism had a major drawback: ivy_switch became a bottleneck
in the import graph, as it both imports from many places in the codebase
and is imported by many modules in the codebase. This frequently resulted
in cyclic imports which caused issues both with TS and Closure compilation.
It turns out ngcc needs both code paths in the bundle to perform the switch
during its operation anyway, so import switching was later abandoned. This
means that there's no real reason why the ivy_switch mechanism needed to
operate at the Bazel level, and for the ivy_switch file to be a bottleneck.
This commit removes the Bazel-level ivy_switch mechanism, and introduces
an additional TypeScript transform in ngtsc (and the pass-through tsc
compiler used for testing JIT) to perform the same operation that ngcc
does, and flip the switch during ngtsc compilation. This allows the
ivy_switch file to be removed, and the individual switches to be located
directly next to their consumers in the codebase, greatly mitigating the
circular import issues and making the mechanism much easier to use.
As part of this commit, the tag for marking switched variables was changed
from __PRE_NGCC__ to __PRE_R3__, since it's no longer just ngcc which
flips these tags. Most variables were renamed from R3_* to SWITCH_* as well,
since they're referenced mostly in render2 code.
Test strategy: existing test coverage is more than sufficient - if this
didn't work correctly it would break the hello world and todo apps.
PR Close#26550
* If all guards return `true`, operator returns `true`
* `false` and `UrlTree` are now both valid returns from a guard
* Both these values wait for higher priority guards to resolve
* Highest priority `false` or `UrlTree` value will be returned
PR Close#26478
Since the SW immediately takes over all clients, it is safe to delete
caches used by older (e.g. beta) `@angular/service-worker` versions to
avoid running into browser storage quota limitations.
PR Close#26319
This commit also removes the extra jasminewd2 typings, since the changes
have been merged in the official typings with
DefinitelyTyped/DefinitelyTyped#28957.
PR Close#26139
Using Renderer’s setElementAttribute or setElementStyle with a null or undefined value removes the
corresponding attribute or style. The argument type should allow this when using strictNullChecks.
Closes#13686
PR Close#17065
The 'animations' field of @Component metadata should be copied directly
into the ngComponentDef for that component and should not pass through
static resolution.
Previously the animations array was statically resolved and then the
values were translated back when generating ngComponentDef.
PR Close#26322
Previously we only removed assignments to `Class.decorators = [];`
if the array was not empty.
Now we also remove calls to `__decorate([])`, similarly.
PR Close#26236
Previously, classes that were declared via variable declarations,
rather than class declarations, were being excluded from the
parsed classes.
PR Close#26236
The most recent Angular distributions have begun to use __decorate instead of Class.decorators.
This prevents `ngcc` from recognizing the classes and then fails to perform the transform to
ivy format.
Example:
```
var ApplicationModule = /** @class */ (function () {
// Inject ApplicationRef to make it eager...
function ApplicationModule(appRef) {
}
ApplicationModule = __decorate([
NgModule({ providers: APPLICATION_MODULE_PROVIDERS }),
__metadata("design:paramtypes", [ApplicationRef])
], ApplicationModule);
return ApplicationModule;
}());
```
Now `ngcc` recognizes `__decorate([...])` declarations and performs its transform.
See FW-379
PR Close#26236
In some formats variables are declared as `var` or `let` and only
assigned a value later in the code.
The ngtsc resolver still needs to be able to resolve this value,
so the host now provides a `host.getVariableValue(declaration)`
method that can do this resolution based on the format.
The hosts make some assumptions about the layout of the
code, so they may only work in the constrained scenarios that
ngcc expects.
PR Close#26236
While creating FESM files, rollup usually drops all unused symbols.
All *__POST_NGCC__ are unused unless ngcc rewires stuff. To prevent this DCE
we reexport them as private symbols. If ngcc is not used, these symbols will
be dropped when we optimize an application bundle.
PR Close#26071
This commit builds on the NgtscTestEnvironment helper work before and
introduces template_typecheck_spec.ts, which contains compiler tests
for template type-checking.
PR Close#26203
This commit gets ready for the introduction of ngtsc template
type-checking tests by refactoring test environment setup into a
custom helper. This helper will simplify the authoring of future
ngtsc tests.
Ngtsc tests previously returned a numeric error code (a la ngtsc's CLI
interface) if any TypeScript errors occurred. The helper has the
ability to run ngtsc and return the actual array of ts.Diagnostics, which
greatly increases the ability to write clean tests.
PR Close#26203
This commit enables generation and checking of a type checking ts.Program
whenever the fullTemplateTypeCheck flag is enabled in tsconfig.json. It
puts together all the pieces built previously and causes diagnostics to be
emitted whenever type errors are discovered in a template.
Todos:
* map errors back to template HTML
* expand set of type errors covered in generated type-check blocks
PR Close#26203
This commit adds an ngTemplateGuard_ngIf static method to the NgIf
directive and an ngTemplateContextGuard static method to NgFor. The
function of these two static methods is to enable type narrowing
within generated type checking code for consumers of the directives.
PR Close#26203
Before type checking can be turned on in ngtsc, appropriate metadata for
each component and directive must be determined. This commit adds tracking
of the extra metadata in *DefWithMeta types to the selector scope handling,
allowing for later extraction for type-checking purposes.
PR Close#26203
This commit introduces the template type-checking context API, which manages
inlining of type constructors and type-check blocks into ts.SourceFiles.
This API will be used by ngtsc to generate a type-checking ts.Program.
An TypeCheckProgramHost is provided which can wrap a normal ts.CompilerHost
and intercept getSourceFile() calls. This can be used to provide source
files with type check blocks to a ts.Program for type-checking.
PR Close#26203
This commit introduces the main functionality of the type-check compiler:
generation of type check blocks. Type check blocks are blocks of TypeScript
code which can be inlined into source files, and when processed by the
TypeChecker will give information about any typing errors in template
expressions.
PR Close#26203
Template type-checking will make use of expression and statement
translation as well as the ImportManager, so this code needs to
live in a separate build target which can be depended on by both
the main ngtsc transform as well as the template type-checking
mechanism. This refactor introduces a separate build target
for that code.
PR Close#26203
Previously in Ivy, metadata for directives/components/modules/etc was
carried in .d.ts files inside type information encoded on the
DirectiveDef, ComponentDef, NgModuleDef, etc types of Ivy definition
fields. This works well, but has the side effect of complicating Ivy's
runtime code as these extra generic type parameters had to be specified
as <any> throughout the codebase. *DefInternal types were introduced
previously to mitigate this issue, but that's the wrong way to solve
the problem.
This commit returns *Def types to their original form, with no metadata
attached. Instead, new *DefWithMeta types are introduced that alias the
plain definition types and add extra generic parameters. This way the
only code that needs to deal with the extra metadata parameters is the
compiler code that reads and writes them - the existence of this metadata
is transparent to the runtime, as it should be.
PR Close#26203
This commit introduces //packages/compiler-cli/src/ngtsc/typecheck as a
container for template type-checking code, and implements an initial API:
type constructor generation.
Type constructors are static methods on component/directive types with
no runtime implementation. The methods are used during compilation to
enable inference of a component or directive's generic type parameters
from the types of expressions bound to any of their @Inputs. A type
constructor looks like:
class Directive<T> {
someInput: T;
static ngTypeCtor<T>(init: Partial<Pick<Directive<T>, 'someInput'>>): Directive<T>;
}
It can be used to infer a type for T based on the input:
const _dir = Directive.ngTypeCtor({someInput: 'string'}); // Directive<T>
PR Close#26203
This commit introduces the "t2" API, which processes parsed template ASTs
and performs a number of functions such as binding (the process of
semantically interpreting cross-references within the template) and
directive matching. The API is modeled on TypeScript's TypeChecker API,
with oracle methods that give access to collected metadata.
This work is a prerequisite for the upcoming template type-checking
functionality, and will also become the basis for a refactored
TemplateDefinitionBuilder.
PR Close#26203
This commit adds a generic type parameter to the SelectorMatcher
class and its associated response types. This makes the API for
matching selectors and obtaining information about the matched
directives significantly more ergonomic and type-safe.
PR Close#26203
Upcoming implementation work for template type-checking will need to reuse the
code which matches directives inside a template, so this refactor commit moves
the code to a shared location in preparation.
This commit pulls the code needed to match directives against a template node
out of the TemplateDefinitionBuilder into a utility function, in preparation
for template type-checking and other TemplateDefinitionBuilder refactoring.
PR Close#26203
* Pull out `activateRoutes` into new operator
* Add `asyncTap` operator
* Use `asyncTap` operator for router hooks and remove corresponding abstracted operators
* Clean up formatting
* Minor performance improvements
PR Close#25740
This is a major refactor of how the router previously worked. There are a couple major advantages of this refactor, and future work will be built on top of it.
First, we will no longer have multiple navigations running at the same time. Previously, a new navigation wouldn't cause the old navigation to be cancelled and cleaned up. Instead, multiple navigations could be going at once, and we imperatively checked that we were operating on the most current `router.navigationId` as we progressed through the Observable streams. This had some major faults, the biggest of which was async races where an ongoing async action could result in a redirect once the async action completed, but there was no way to guarantee there weren't also other redirects that would be queued up by other async actions. After this refactor, there's a single Observable stream that will get cleaned up each time a new navigation is requested.
Additionally, the individual pieces of routing have been pulled out into their own operators. While this was needed in order to create one continuous stream, it also will allow future improvements to the testing APIs as things such as Guards or Resolvers should now be able to be tested in much more isolation.
* Add the new `router.transitions` observable of the new `NavigationTransition` type to contain the transition information
* Update `router.navigations` to pipe off of `router.transitions`
* Re-write navigation Observable flow to a single configured stream
* Refactor `switchMap` instead of the previous `mergeMap` to ensure new navigations cause a cancellation and cleanup of already running navigations
* Wire in existing error and cancellation logic so cancellation matches previous behavior
PR Close#25740
In some cases, example when the user clears the caches in DevTools but
the SW remains active on another tab and keeps references to the deleted
caches, trying to write to the cache throws errors (e.g.
`Entry was not found`).
When this happens, the SW can no longer work correctly and should enter
a degraded mode allowing requests to be served from the network.
Possibly related:
- https://github.com/GoogleChrome/workbox/issues/792
- https://bugs.chromium.org/p/chromium/issues/detail?id=639034
This commits remedies this situation, by ensuring the SW can enter the
degraded `EXISTING_CLIENTS_ONLY` mode and forward requests to the
network.
PR Close#26042
Properties are not allowed usage notes, and in this case the example
is so simple it didn't warrant moving it to the overall class documentation.
PR Close#26039
* Pull out `activateRoutes` into new operator
* Add `asyncTap` operator
* Use `asyncTap` operator for router hooks and remove corresponding abstracted operators
* Clean up formatting
* Minor performance improvements
PR Close#25740
This is a major refactor of how the router previously worked. There are a couple major advantages of this refactor, and future work will be built on top of it.
First, we will no longer have multiple navigations running at the same time. Previously, a new navigation wouldn't cause the old navigation to be cancelled and cleaned up. Instead, multiple navigations could be going at once, and we imperatively checked that we were operating on the most current `router.navigationId` as we progressed through the Observable streams. This had some major faults, the biggest of which was async races where an ongoing async action could result in a redirect once the async action completed, but there was no way to guarantee there weren't also other redirects that would be queued up by other async actions. After this refactor, there's a single Observable stream that will get cleaned up each time a new navigation is requested.
Additionally, the individual pieces of routing have been pulled out into their own operators. While this was needed in order to create one continuous stream, it also will allow future improvements to the testing APIs as things such as Guards or Resolvers should now be able to be tested in much more isolation.
* Add the new `router.transitions` observable of the new `NavigationTransition` type to contain the transition information
* Update `router.navigations` to pipe off of `router.transitions`
* Re-write navigation Observable flow to a single configured stream
* Refactor `switchMap` instead of the previous `mergeMap` to ensure new navigations cause a cancellation and cleanup of already running navigations
* Wire in existing error and cancellation logic so cancellation matches previous behavior
PR Close#25740
`TypeScript` only supports merging and extending of `compilerOptions`. This is an implementation to support extending and inheriting of `angularCompilerOptions` from multiple files.
Closes: #22684
PR Close#22717
Previously, when you attempted to bootstrap a component that had a
router-outlet using ngsummaries, it would complain that the component
was not provided by any module even if it was. This commit fixes a
mistake (AFAICT) which caused the lookup of the component in the AOT
summaries to fail.
I believe this change is safe. I've run the affected tests within Google
and there were no breakages caused by this change.
PR Close#24892
Create getter methods `getXXXDef` for each definition which
uses `hasOwnProperty` to verify that we don't accidently read form the
parent class.
Fixes: #24011Fixes: #25026
PR Close#25736
Various user code uses 'instanceof' to check whether a particular instance
is a TemplateRef, ElementRef, etc. Ivy needs to work with these checks.
PR Close#25775
Previously, if ngtsc encountered a VariableDeclaration without an
initializer, it would assume that the variable was undefined, and
return that result.
However, for symbols exported from external modules that resolve to
.d.ts files, variable declarations are of the form:
export declare let varName: Type;
This form also lacks an initializer, but indicates the presence of an
importable symbol which can be referenced. This commit changes the
static resolver to understand variable declarations with the 'declare'
keyword and to generate references when it encounters them.
PR Close#25775
The bootstrap property of @NgModule was not previously compiled by
the compiler in AOT or JIT modes (in Ivy). This commit adds support
for bootstrap.
PR Close#25775
Closure requires @nocollapse on Ivy definition static fields in order
to not convert them to standalone constants. However tsickle, the tool
which would ordinarily be responsible for adding @nocollapse, doesn't
properly annotate fields which are added synthetically via transforms.
So this commit adds @nocollapse by applying regular expressions against
code during the final write to disk.
PR Close#25775
This fix is for the issue below when compiling I18N Angular apps using closure.
For certain locales closure converts the input locale id to a different equivalent locale string. For example if the input locale is 'id'(for Indonesia) goog.LOCALE is set to 'in' and the closure locale data is registered only for 'in'. The Angular compiler uses the original input locale string, 'id' to set the LOCALE_ID token and there is a mismatch of locale used to register and locale used when requesting the locale data.
The fix is for the closure-locale.ts code to register the locale data for all equivalent locales names so that it doesn't matter what goog.LOCALE is actually set to.
PR Close#25867
Add following to your `~/.bazelrc`. This will run the build faster locally
(outside of sandbox), but continue running the builds with sandboxing
on CI.
```
build --spawn_strategy=standalone --strategy=ESM5=sandboxed
```
PR Close#25870
`ngcc` adds marker files to each folder that has been
compiled, containing the version of the ngcc used.
When compiling, it will ignore folders that contain these
marker files, as long as the version matches.
PR Close#25557
defineComponent() and friends can return a flyweight EMPTY object for
specific fields when they contain no data. InheritDefinitionFeature
was attempting to write into these flyweight objects, which have been
protected with Object.freeze().
This commit adds detection to InheritDefinitionFeature to identify the
frozen objects.
PR Close#25755
While creating FESM files, rollup usually drops all unused symbols.
All *__POST_NGCC__ are unused unless ngcc rewires stuff. To prevent this DCE
we reexport them as private symbols. If ngcc is not used, these symbols will
be dropped when we optimize an application bundle.
We don't have an infrastructure to test this fix, so I just manually inspected
the bundles before and after to verify that the fix works.
PR Close#25780
Closure compiler requires that the i18n message constants of the form
const MSG_XYZ = goog.getMessage('...');
have names that are unique across an entire compilation, even if the
variables themselves are local to a given module. This means that in
practice these names must be unique in a codebase.
The best way to guarantee this requirement is met is to encode the
relative file name of the file into which the constant is being written
into the constant name itself. This commit implements that solution.
PR Close#25689
Marc Laval
Alex Eagle
Kara Erickson
Jason Aden
Miško Hevery
Keen Yee Liau
Igor Minar
Paul Gschwendtner
Keen Yee Liau
Andrew Kushnir
Olivier Combe
Brandon Roberts
Pete Bacon Darwin
Pawel Kozlowski
JoostK
cyraid
Ruslan Dzhabbarov
levgaas
Ingo Bürk
cexbrayat
Christopher Dahm
cooljeffro
Kristiyan Kostadinov
Alex Eagle
Alex Rickabaugh
Greg Magolan
Sander Elias
Ben Lesh
miginmrs
George Kalpakas
Matias Niemelä
Christopher Dahm
Alex Eagle
ryo.s
Igor Minar
Huáng Jùnliàng
Trotyl Yu
Nick Tobolski
mrmeku
Sarun Intaralawan
Charles Lyding
Judy Bogart
Deltatiger
Andrew Lobban
Andrew Grekov
Andy Blatecky
Lars Gyrup Brink Nielsen
Alan Agius
joostme
Joost Zöllner
Shino Kurian
Anthony Ciccarello
Manduro
Jason Bedard
krzysztof-grzybek
JiaLi.Passion
Ash Kyd
Frederik Schlemmer
Adam Plumer
George Wilde
Daniel Wiehl
vincecampanale
Matt Keller
Greg Estren
Vikram Subramanian