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