Commit Graph

3742 Commits

Author SHA1 Message Date
Sam Julien 0ddf2e7a5b fix(upgrade): do not break if `onMicrotaskEmpty` emits while a `$digest` is in progress (#29794)
Previously, under certain circumstances, `NgZone#onMicrotaskEmpty` could
emit while a `$digest` was in progress, thus triggering another
`$digest`, which in turn would throw a `$digest already in progress`
error. Furthermore, throwing an error from inside the `onMicrotaskEmpty`
subscription would result in unsubscribing and stop triggering further
`$digest`s, when `onMicrotaskEmpty` emitted.

Usually, emitting while a `$digest` was already in progress was a result
of unintentionally running some part of AngularJS outside the Angular
zone, but there are valid (if rare) usecases where this can happen
(see #24680 for details).

This commit addresses the issue as follows:
- If a `$digest` is in progress when `onMicrotaskEmpty` emits, do not
  trigger another `$digest` (to avoid the error). `$evalAsync()` is used
  instead, to ensure that the bindings are evaluated at least once more.
- Since there is still a high probability that the situation is a result
  of programming error (i.e. some AngularJS part running outside the
  Angular Zone), a warning will be logged, but only if the app is in
  [dev mode][1].

[1]: https://github.com/angular/angular/blob/78146c189/packages/core/src/util/ng_dev_mode.ts#L12

Fixes #24680

PR Close #29794
2019-04-25 11:00:36 -07:00
Alex Rickabaugh d316a18dc6 fix(ivy): don't include query fields in type constructors (#30094)
Previously, ngtsc included query fields in the list of fields which can
affect the type of a directive via its type constructor. This feature
however has yet to be built, and View Engine in default mode does not
do this inference.

This caused an unexpected bug where private query fields (which should be
an error but are allowed by View Engine) cause the type constructor
signature to be invalid. This commit fixes that issue by disabling the
logic to include query fields.

PR Close #30094
2019-04-24 17:10:21 -07:00
Alex Rickabaugh 79141f4424 fix(ivy): generate default 'any' types for type ctor generic params (#30094)
ngtsc generates type constructors which infer the type of a directive based
on its inputs. Previously, a bug existed where this inference would fail in
the case of 'any' input values. For example, the inference of NgForOf fails
when an 'any' is provided, as it causes TypeScript to attempt to solve:

T[] = any

In this case, T gets inferred as {}, the empty object type, which is not
desirable.

The fix is to assign generic types in type constructors a default type of
'any', which TypeScript uses instead of {} when inference fails.

PR Close #30094
2019-04-24 17:10:21 -07:00
Keen Yee Liau 28fd5ab12b fix(compiler): Fix compiler crash due to isSkipSelf of null (#30075)
PR Closes https://github.com/angular/angular/issues/27125

PR Close #30075
2019-04-24 17:06:53 -07:00
Alex Rickabaugh c61df39323 feat(router): deprecate loadChildren:string (#30073)
The proposed ES dynamic import() is now supported by the Angular CLI and the
larger toolchain. This renders the `loadChildren: string` API largely
redundant, as import() is far more natural, is less error-prone, and is
standards compliant. This commit deprecates the `string` form of
`loadChildren` in favor of dynamic import().

DEPRECATION:

When defining lazy-loaded route, Angular previously offered two options for
configuring the module to be loaded, both via the `loadChildren` parameter
of the route. Most Angular developers are familiar withthe `string` form of
this API. For example, the following route definition configures Angular to
load a `LazyModule` NgModule from `lazy-route/lazy.module.ts`:

```
[{
  path: 'lazy',
  loadChildren: 'lazy-route/lazy.module#LazyModule',
}]
```

This "magic string" configuration was previously necessary as there was
no dynamic module loading standard on the web. This has changed with the
pending standardization of dynamic `import()` expressions, which are now
supported in the Angular CLI and in web tooling in general. `import()`
offers a more natural and robust solution to dynamic module loading. The
above example can be rewritten to use dynamic `import()`:

```
[{
  path: 'lazy',
  loadChildren: () => import('./lazy-route/lazy.module').then(mod => mod.LazyModule),
}]
```

This form of lazy loading offers significant advantages in terms of:

* type checking via TypeScript
* simplicity of generated code
* future potential to run natively in supporting browsers
  (see: [caniuse: dynamic import()](https://caniuse.com/#feat=es6-module-dynamic-import))

As a result, Angular is deprecating the `loadChildren: string` syntax in
favor of ES dynamic `import()`. An automatic migration will run during
`ng upgrade` to convert your existing Angular code to the new syntax.

PR Close #30073
2019-04-24 17:06:05 -07:00
George Kalpakas abcb2cf9a0 refactor(upgrade): rename `module` constant to avoid webpack bug (#30058)
When targeting ES2015 (as is the default in cli@8), `const` is not
downleveled to `var` and thus declaring `const module` throws an error
due to webpack wrapping the code in a function call with a `module`
argument (even when compiling for the `web` environment).

Related: webpack/webpack#7369

Fixes #30050

PR Close #30058
2019-04-24 17:03:51 -07:00
Jason Aden 071ee64d91 refactor(common): rename LocationUpgradeService and remove angular/upgrade dependency (#30055)
PR Close #30055
2019-04-24 13:49:29 -07:00
Jason Aden efdbbe1aa6 test(common): add fallback for URL parsing in older browsers (IE < Edge) (#30055)
PR Close #30055
2019-04-24 13:49:29 -07:00
Jason Aden 4277600d5e feat(common): provide replacement for AngularJS $location service (#30055)
This commit provides a replacement for `$location`. The new service is written in Angular, and can be consumed into existing applications by using the downgraded version
of the provider.

Prior to this addition, applications upgrading from AngularJS to Angular could get into a situation where AngularJS wanted to control the URL, and would often parse or se
rialize the URL in a different way than Angular. Additionally, AngularJS was alerted to URL changes only through the `$digest` cycle. This provided a buggy feedback loop
from Angular to AngularJS.

With this new `LocationUpgradeProvider`, the `$location` methods and events are provided in Angular, and use Angular APIs to make updates to the URL. Additionally, change
s to the URL made by other parts of the Angular framework (such as the Router) will be listened for and will cause events to fire in AngularJS, but will no longer attempt
 to update the URL (since it was already updated by the Angular framework).

This centralizes URL reads and writes to Angular and should help provide an easier path to upgrading AngularJS applications to Angular.

PR Close #30055
2019-04-24 13:49:29 -07:00
Jason Aden f185ff3792 build(common): add upgrade package dependency common/upgrade (#30055)
PR Close #30055
2019-04-24 13:49:29 -07:00
Jason Aden ec455e1cf1 feat(common): add UrlCodec type for use with upgrade applications (#30055)
This abstract class (and AngularJSUrlCodec) are used for serializing and deserializing pieces of a URL string. AngularJS had a different way of doing this than Angular, and using this class in conjunction with the LocationUpgradeService an application can have control over how AngularJS URLs are serialized and deserialized.

PR Close #30055
2019-04-24 13:49:29 -07:00
Jason Aden 825efa8721 fix(common): adjust MockPlatformLocation to set state to new object (#30055)
When using the `history` API, setting a new `state` and retrieving it does not pass a `===` test to the object used to set the state. In other words, `history.state` is always a copy. This change makes the `MockPlatformLocation` behave in the same way.

PR Close #30055
2019-04-24 13:49:29 -07:00
Jason Aden 3a9cf3f2ba feat(common): add ability to track all location changes (#30055)
This feature adds an `onUrlChange` to Angular's `Location` class. This is useful to track all updates coming from anywhere in the framework. Without this method, it's difficult (or impossible) to track updates run through `location.go()` or `location.replaceState()` as the browser doesn't publish events when `history.pushState()` or `.replaceState()` are run.

PR Close #30055
2019-04-24 13:49:29 -07:00
Jason Aden 152d99eef0 feat(common): add @angular/common/upgrade package for $location-related APIs (#30055)
AngularJS's `$location` service doesn't have a direct counterpart in Angular. This is largely because the `Location` service in Angular was pulled out of the `Router`, but was not purpose-built to stand on its own.

This commit adds a new `@angular/common/upgrade` package with the beginnings of a new `LocationUpgradeService`. This service will more closely match the API of AngularJS and provide a way to replace the `$location` service from AngularJS.

PR Close #30055
2019-04-24 13:49:29 -07:00
Jason Aden b635fe80cc feat(common): add APIs to read component pieces of URL (#30055)
Without this change, the framework doesn't surface URL parts such as hostname, protocol, and port. This makes it difficult to rebuild a complete URL. This change provides new APIs to read these values.

PR Close #30055
2019-04-24 13:49:29 -07:00
Jason Aden b44b14368f feat(common): add ability to retrieve the state from Location service (#30055)
Previously there wasn't a way to retrieve `history.state` from the `Location` service. The only time the framework exposed this value was in navigation events. This meant if you weren't using the Angular router, there wasn't a way to get access to this `history.state` value other than going directly to the DOM.

This PR adds an API to retrieve the value of `history.state`. This will be useful and needed to provide a backwards-compatible `Location` service that can emulate AngularJS's `$location` service since we will need to be able to read the state data in order to produce AngularJS location transition events.

This feature will additionally be useful to any application that wants to access state data through Angular rather than going directly to the DOM APIs.

PR Close #30055
2019-04-24 13:49:28 -07:00
Jason Aden d0672c252e feat(common): add MockPlatformLocation to enable more robust testing of Location services (#30055)
Prior to this change we had a MockLocationStrategy to replace the Path and Hash Location Strategies. However, there wasn't a good way to test the PlatformLocation which is needed for doing things such as setting history.state, using back()/forward(), etc.

PR Close #30055
2019-04-24 13:49:28 -07:00
Alex Rickabaugh 3938563565 fix(ivy): don't reuse a ts.Program more than once in ngtsc (#30090)
ngtsc previously could attempt to reuse the main ts.Program twice. This
occurred when template type-checking was enabled and then an incremental
build was performed. This breaks a TypeScript invariant - ts.Programs can
only be reused once.

The creation of the template type-checking program reuses the main program,
rendering it moot. Then, on the next incremental build the main program
would be subject to reuse again, which would crash inside TypeScript.

This commit fixes the issue by reusing the template type-checking program
from the previous run on the next incremental build. Since under normal
circumstances the files in the type-checking program aren't changed, this
should be just as fast.

Testing strategy: a test is added in the incremental_spec which validates
that program reuse with type-checking turned on does not crash the compiler.

Fixes #30079

PR Close #30090
2019-04-24 11:41:21 -07:00
Kristiyan Kostadinov ae93ba1140 fix(ivy): don't throw error when evaluating function with more than one statement (#30061)
Resolves functions with more than one statement to unknown dynamic values, rather than throwing an error.

PR Close #30061
2019-04-24 11:32:56 -07:00
Kristiyan Kostadinov 2e21997016 perf(ivy): remove megamorphic read from renderStringify (#30082)
The `renderStringify` function is used in a lot of performance-sensitive places, however it contains a megamorphic read which is used primarily for error messages. These changes introduce a new function that can be used to stringify output for errors and removes the megamorphic read from `renderStringify`.

This PR resolves FW-1286.

PR Close #30082
2019-04-24 11:31:48 -07:00
Pete Bacon Darwin 0fa76219ac refactor(ivy): ngcc - simplify `NewEntryPointFileWriter` code (#30085)
The lines that compute the paths for this writer were confusing.
This commit simplifies and clarifies what is being computed.

PR Close #30085
2019-04-24 10:49:31 -07:00
Pete Bacon Darwin 6af9b8fb92 fix(ivy): ngcc - do not copy external files when writing bundles (#30085)
Only the JS files that are actually part of the entry-point
should be copied to the new entry-point folder in the
`NewEntryPointFileWriter`.

Previously some typings and external JS files were
being copied which was messing up the node_modules
structure.

Fixes https://github.com/angular/angular-cli/issues/14193

PR Close #30085
2019-04-24 10:49:31 -07:00
Keen Yee Liau 0b5f480eca fix(bazel): make name param in ng add optional (#30074)
PR Close #30074
2019-04-24 10:45:42 -07:00
Keen Yee Liau 2905bf5548 fix(bazel): Make sure only single copy of `@angular/bazel` is installed (#30072)
When `ng add` is invoked independently of `ng new`, a node installation
of `@angular/bazel` is performed by the CLI before invoking the
schematic. This step appends `@angular/bazel` to the `dependencies`
section of `package.json`. The schematics then appends the same package
to `devDependencies`.

This leads to the warning:

```
warning package.json: "dependencies" has dependency "@angular/bazel" with
range "^8.0.0-beta.13" that collides with a dependency in "devDependencies"
of the same name with version "~8.0.0-beta.12"
```

PR Close #30072
2019-04-24 10:44:42 -07:00
Kristiyan Kostadinov c7f1b0a97f fix(ivy): queries not being inherited from undecorated classes (#30015)
Fixes view and content queries not being inherited in Ivy, if the base class hasn't been annotated with an Angular decorator (e.g. `Component` or `Directive`).

Also reworks the way the `ngBaseDef` is created so that it is added at the same point as the queries, rather than inside of the `Input` and `Output` decorators.

This PR partially resolves FW-1275. Support for host bindings will be added in a follow-up, because this PR is somewhat large as it is.

PR Close #30015
2019-04-24 10:38:44 -07:00
Kristiyan Kostadinov d92fb25161 feat(ivy): add injectable-pipe schematic (#29847)
Adds a schematic that will annotate all `Pipe` classes with `Injectable` so that they can be injected.

This PR resolves FW-1228.

PR Close #29847
2019-04-23 15:12:19 -07:00
Andrew Kushnir aaf8145c48 fix(ivy): support module.id as @NgModule's "id" field value (#30040)
Prior to this commit, the check that verifies correct "id" field type was too strict and didn't allow `module.id` as @NgModule's "id" field value. This change adds a special handling for `module.id` and uses it as id of @NgModule if specified.

PR Close #30040
2019-04-23 14:50:58 -07:00
JoostK c4dd2d115b fix(ivy): let ngtsc's shim host delegate `resolveModuleNames` method (#30068)
Now that ngtsc performs type checking using a dedicated `__ng_typecheck__.ts`
file, `NgtscProgram` always wraps its `ts.CompilerHost` in a shim host. This
shim fails to delegate `resolveModuleNames` so no custom module resolution
logic is considered. This introduces a problem for the CLI, as the compiler
host it passes kicks of ngcc for any imported module such that Ivy's
compatibility compiler runs automatically behind the scenes.

This commit adds delegation of the `resolveModuleNames` to fix the issue.

Fixes #30064

PR Close #30068
2019-04-23 13:05:25 -07:00
JoostK 8e8e89a119 fix(common): prevent repeated application of HttpParams mutations (#29045)
Previously, an instance of HttpParams would retain its list of mutations
after they have been materialized as a result of a read operation. Not
only does this unnecessarily hold onto memory, more importantly does it
introduce a bug where branching of off a materialized instance would
reconsider the set of mutations that had already been applied, resulting
in repeated application of mutations.

This commit fixes the bug by clearing the list of pending mutations
after they have been materialized, such that they will not be considered
once again for branched off instances.

Fixes #20430

PR Close #29045
2019-04-23 08:43:54 -07:00
Paul Gschwendtner 364250e7a6 refactor(core): static-query migration should not fail for test files (#30034)
Currently when someone runs `ng update` with the static-query migration,
the migration can fail with an error saying that the `AOT` compiler could not
be created. This can happen if the CLI project contains a test `tsconfig.json`
that is picked up by the schematic.

Due to the fact that spec tsconfig files cannot be ran with NGC (e.g. test
components are not part of a module; not all source files are guaranteed to
be included), test `tsconfig` projects will now use a new `test` migration
strategy where all queries within tests are left untouched and a TODO is added.

PR Close #30034
2019-04-23 08:32:35 -07:00
Andrew Kushnir 00ce9aab5b fix(ivy): explicitly compile ngModuleDef for RootScopeModule in R3TestBed (#30037)
This commit unifies the way auxillary RootScopeModule and DynamicTestModule are compiled in R3TestBed by calling `compileNgModuleDefs` explicitly for RootScopeModule. This change also resolves the problem where TestBed's code was used from the @angular/core NPM package: due to the "jit" flag, the @NgModule decorator on the RootScopeModule was transformed to RootScopeModule.decorators = [...], but actual ngModuleDef was never defined.

PR Close #30037
2019-04-23 08:31:42 -07:00
Alex Rickabaugh 8e73f9b0aa feat(compiler-cli): lower some exported expressions (#30038)
The compiler uses metadata to represent what it statically knows about
various expressions in a program. Occasionally, expressions in the program
for which metadata is extracted may contain sub-expressions which are not
representable in metadata. One such construct is an arrow function.

The compiler does not always need to understand such expressions completely.
For example, for a provider defined with `useValue`, the compiler does not
need to understand the value at all, only the outer provider definition. In
this case, the compiler employs a technique known as "expression lowering",
where it rewrites the provider expression into one that can be represented
in metadata. Chiefly, this involves extracting out the dynamic part (the
`useValue` expression) into an exported constant.

Lowering is applied through a heuristic, which considers the containing
statement as well as the field name of the expression.

Previously, this heuristic was not completely accurate in the case of
route definitions and the `loadChildren` field, which is lowered. If the
route definition using `loadChildren` existed inside a decorator invocation,
lowering was performed correctly. However, if it existed inside a standalone
variable declaration with an export keyword, the heuristic would conclude
that lowering was unnecessary. For ordinary providers this is true; however
the compiler attempts to fully understand the ROUTES token and thus even if
an array of routes is declared in an exported variable, any `loadChildren`
expressions within still need to be lowered.

This commit enables lowering of already exported variables under a limited
set of conditions (where the initializer expression is of a specific form).
This should enable the use of `loadChildren` in route definitions.

PR Close #30038
2019-04-23 08:30:58 -07:00
Trevor Karjanis 9873356bd0 docs: fix grammatical errors in the guides and API documentation (#29928)
Fix grammatical errors in the DI and HttpClient guides as well as the Resolve API documentaiton.

There is no associated issue.

PR Close #29928
2019-04-22 17:32:30 -07:00
Ben Lesh 0f9230d018 feat(ivy): generate ɵɵproperty in host bindings (#30009)
PR Close #30009
2019-04-22 17:30:17 -07:00
JoostK 19dfadb717 fix(ivy): include context name for template functions for `ng-content` (#30025)
Previously, a template's context name would only be included in an embedded
template function if the element that the template was declared on has a
tag name. This is generally true for elements, except for `ng-content`
that does not have a tag name. By omitting the context name the compiler
could introduce duplicate template function names, which would fail at runtime.

This commit fixes the behavior by always including the context name in the
template function's name, regardless of tag name.

Resolves FW-1272

PR Close #30025
2019-04-22 17:28:36 -07:00
Ben Lesh 0bcb2320ba feat(ivy): generate ɵɵpropertyInterpolateX instructions (#30008)
- Compiler now generates `ɵɵpropertyInterpolateX` instructions.

PR Close #30008
2019-04-22 17:10:36 -07:00
José I. Escudero 0cab43785b docs: fixed typo on HttpParamsOptions (#29930)
PR Close #29930
2019-04-22 16:36:52 -07:00
JoostK 8c80b851c8 fix(ivy): ngcc - insert new imports after existing ones (#30029)
Previously, ngcc would insert new imports at the beginning of the file, for
convenience. This is problematic for imports that have side-effects, as the
side-effects imposed by such imports may affect the behavior of subsequent
imports.

This commit teaches ngcc to insert imports after any existing imports. Special
care has been taken to ensure inserted constants will still follow after the
inserted imports.

Resolves FW-1271

PR Close #30029
2019-04-22 16:29:30 -07:00
Kristiyan Kostadinov 63523f7964 fix(ivy): avoid generating instructions for empty style and class bindings (#30024)
Fixes Ivy throwing an error because it tries to generate styling instructions for empty `style` and `class` bindings.

This PR resolves FW-1274.

PR Close #30024
2019-04-22 11:16:58 -07:00
Paul Gschwendtner a9242c4fc2 refactor(core): template-var-assignment migration incorrectly warns (#30026)
Currently the `template-var-assignment` migration incorrectly warns if
the template writes to a property in the component that has the same
`ast.PropertyWrite´ name as a template input variable but different
receiver. e.g.

```html
<!-- "someProp.element" will be incorrectly reported as template variable assignment -->
<button *ngFor="let element of list" (click)="someProp.element = null">Reset</button>
```

Similarly if an output writes to a component property with the same name as a
template input variable, but the expression is within a different template scope,
the schematic currently incorrectly warns. e.g.

```html
<button *ngFor="let element of list">{{element}}</button>

<!-- The "element = null" expression does not refer to the "element" template input variable -->
<button (click)="element = null"></button>
```

PR Close #30026
2019-04-22 11:16:19 -07:00
Ben Lesh 94aeeec1dc build: update rxjs version requirements to 6.4.0 (#30032)
PR Close #30032
2019-04-22 11:15:33 -07:00
Adam Plumer 645e305733 feat(core): add schematics to move deprecated DOCUMENT import (#29950)
PR Close #29950
2019-04-22 08:48:48 -07:00
Kara Erickson f53d0fd2d0 fix(ivy): classes should not mess up matching for bound dir attributes (#30002)
Previously, we had a bug where directive matching could fail if the directive
attribute was bound and followed a certain number of classes. This is because
in the matching logic, we were treating classes like normal attributes. We
should instead be skipping classes in the attribute matching logic. Otherwise
classes will match for directives with attribute selectors, and as we are
iterating through them in twos (when they are stored as name-only, not in
name-value pairs), it may throw off directive matching for any bound attributes
that come after. This commit changes the directive matching logic to skip
classes altogether.

PR Close #30002
2019-04-22 08:48:08 -07:00
Keen Yee Liau 96a828993f fix(bazel): restore ng build --prod (#30005)
`ng build` by default builds the prodapp because there is not
a dev build in Bazel. This PR restores the `--prod` to do the
same to prevent achitect from showing missing config error.

PR Close #30005
2019-04-22 08:47:21 -07:00
JoostK 8cba4e1f6b fix(ivy): ngcc - do not copy declaration files into bundle clone (#30020)
Previously, all of a program's files would be copied into the __ivy_ngcc__
folder where ngcc then writes its modifications into. The set of source files
in a program however is much larger than the source files contained within
the entry-point of interest, so many more files were copied than necessary.
Even worse, it may occur that an unrelated file in the program would collide
with an already existing source file, resulting in incorrectly overwriting
a file with unrelated content. This behavior has actually been observed
with @angular/animations and @angular/platform-browser/animations, where
the former package would overwrite declaration files of the latter package.

This commit fixes the issue by only copying relevant source files when cloning
a bundle's content into __ivy_ngcc__.

Fixes #29960

PR Close #30020
2019-04-22 08:46:19 -07:00
Trotyl Yu 3f6bf6dfd1 fix(common): properly check NaN value (#22305)
closes #15721

PR Close #22305
2019-04-19 19:36:39 -07:00
JoostK c3c0df9d56 fix(ivy): let ngtsc evaluate default parameters in the callee context (#29888)
Previously, during the evaluation of a function call where no argument
was provided for a parameter that has a default value, the default value
would be taken from the context of the caller, instead of the callee.

This commit fixes the behavior by resolving the default value of a
parameter in the context of the callee.

PR Close #29888
2019-04-19 19:30:40 -07:00
JoostK cb34514d05 feat(ivy): let ngtsc evaluate the spread operator in function calls (#29888)
Previously, ngtsc's static evaluator did not take spread operators into
account when evaluating function calls, nor did it handle rest arguments
correctly. This commit adds support for static evaluation of these
language features.

PR Close #29888
2019-04-19 19:30:40 -07:00
Ben Lesh f348deae92 test: put host binding acceptances tests in their own file (#29946)
PR Close #29946
2019-04-19 16:07:52 -07:00
Ben Lesh 10217bb3bc feat(ivy): generate ɵɵproperty instructions (#29946)
PR Close #29946
2019-04-19 16:07:52 -07:00
Kristiyan Kostadinov 6ae0084255 fix(ivy): error when calling remove() or detach() on an empty view container (#29986)
Fixes Ivy throwing an error if `remove()` or `detach()` are called on an empty `ViewContainerRef`.

This PR resolves FW-1270.

PR Close #29986
2019-04-19 14:18:48 -07:00
Olivier Combe 4e13700ad2 fix(ivy): set ng-reflect properties for unbound directive inputs (#29973)
We only set ng-reflect properties on directive input bindings.
This PR ensures that we also add ng-reflect properties on unbound inputs for backwards compatibility.

FW-1266 #resolve

PR Close #29973
2019-04-19 14:15:46 -07:00
Alex Rickabaugh d9ce8a4ab5 feat(ivy): introduce a flag to control template type-checking for Ivy (#29698)
Template type-checking is enabled by default in the View Engine compiler.
The feature in Ivy is not quite ready for this yet, so this flag will
temporarily control whether templates are type-checked in ngtsc.

The goal is to remove this flag after rolling out template type-checking in
google3 in Ivy mode, and making sure the feature is as compatible with the
View Engine implementation as possible.

Initially, the default value of the flag will leave checking disabled.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh 42262e4e8c feat(ivy): support $any when type-checking templates (#29698)
This commit adds support in the template type-checking engine for the $any
cast operation.

Testing strategy: TCB tests included.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh bea85ffe9c fix(ivy): match microsyntax template directives correctly (#29698)
Previously, Template.templateAttrs was introduced to capture attribute
bindings which originated from microsyntax (e.g. bindings in *ngFor="...").
This means that a Template node can have two different structures, depending
on whether it originated from microsyntax or from a literal <ng-template>.

In the literal case, the node behaves much like an Element node, it has
attributes, inputs, and outputs which determine which directives apply.
In the microsyntax case, though, only the templateAttrs should be used
to determine which directives apply.

Previously, both the t2_binder and the TemplateDefinitionBuilder were using
the wrong set of attributes to match directives - combining the attributes,
inputs, outputs, and templateAttrs of the Template node regardless of its
origin. In the TDB's case this wasn't a problem, since the TDB collects a
global Set of directives used in the template, so it didn't matter whether
the directive was also recognized on the <ng-template>. t2_binder's API
distinguishes between directives on specific nodes, though, so it's more
sensitive to mismatching.

In particular, this showed up as an assertion failure in template type-
checking in certain cases, when a directive was accidentally matched on
a microsyntax template element and also had a binding which referenced a
variable declared in the microsyntax. This resulted in the type-checker
attempting to generate a reference to a variable that didn't exist in that
scope.

The fix is to distinguish between the two cases and select the appropriate
set of attributes to match on accordingly.

Testing strategy: tested in the t2_binder tests.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh 5268ae61a0 feat(ivy): support for template type-checking pipe bindings (#29698)
This commit adds support for template type-checking a pipe binding which
previously was not handled by the type-checking engine. In compatibility
mode, the arguments to transform() are not checked and the type returned
by a pipe is 'any'. In full type-checking mode, the transform() method's
type signature is used to check the pipe usage and infer the return type
of the pipe.

Testing strategy: TCB tests included.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh 98f86de8da perf(ivy): template type-check the entire program in 1 file if possible (#29698)
The template type-checking engine previously would assemble a type-checking
program by inserting Type Check Blocks (TCBs) into existing user files. This
approach proved expensive, as TypeScript has to re-parse and re-type-check
those files when processing the type-checking program.

Instead, a far more performant approach is to augment the program with a
single type-checking file, into which all TCBs are generated. Additionally,
type constructors are also inlined into this file.

This is not always possible - both TCBs and type constructors can sometimes
require inlining into user code, particularly if bound generic type
parameters are present, so the approach taken is actually a hybrid. These
operations are inlined if necessary, but are otherwise generated in a single
file.

It is critically important that the original program also include an empty
version of the type-checking file, otherwise the shape of the two programs
will be different and TypeScript will throw away all the old program
information. This leads to a painfully slow type checking pass, on the same
order as the original program creation. A shim to generate this file in the
original program is therefore added.

Testing strategy: this commit is largely a refactor with no externally
observable behavioral differences, and thus no tests are needed.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh f4c536ae36 feat(ivy): logical not and safe navigation operation handling in TCBs (#29698)
This commit adds support in the template type-checking engine for handling
the logical not operation and the safe navigation operation.

Safe navigation in particular is tricky, as the View Engine implementation
has a rather inconvenient flaw. View Engine checks a safe navigation
operation `a?.b` as:

```typescript
(a != null ? a!.b : null as any)
```

The type of this expression is always 'any', as the false branch of the
ternary has type 'any'. Thus, using null-safe navigation throws away the
type of the result, and breaks type-checking for the rest of the expression.

A flag is introduced in the type-checking configuration to allow Ivy to
mimic this behavior when needed.

Testing strategy: TCB tests included.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh 182e2c7449 feat(ivy): add backwards compatibility config to template type-checking (#29698)
View Engine's implementation of naive template type-checking is less
advanced than the current Ivy implementation. As a result, Ivy catches lots
of typing bugs which VE does not. As a result, it's necessary to tone down
the Ivy template type-checker in the default case.

This commit introduces a mechanism for doing that, by passing a config to
the template type-checking engine. Through this configuration, particular
checks can be loosened or disabled entirely.

Testing strategy: TCB tests included.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh cd1277cfb7 fix(ivy): include directive base class metadata when generating TCBs (#29698)
Previously the template type-checking code only considered the metadata of
directive classes actually referenced in the template. If those directives
had base classes, any inputs/outputs/etc of the base classes were not
tracked when generating the TCB. This resulted in bindings to those inputs
being incorrectly attributed to the host component or element.

This commit uses the new metadata package to follow directive inheritance
chains and use the full metadata for a directive for TCB generation.

Testing strategy: Template type-checking tests included.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh 9277afce61 refactor(ivy): move metadata registration to its own package (#29698)
Previously, metadata registration (the recording of collected metadata
during analysis of directives, pipes, and NgModules) was only used to
produce the `LocalModuleScope`, and thus was handled by the
`LocalModuleScopeRegistry`.

However, the template type-checker also needs information about registered
directives, outside of the NgModule scope determinations. Rather than
reuse the scope registry for an unintended purpose, this commit introduces
new abstractions for metadata registration and lookups in a separate
'metadata' package, which the scope registry implements.

This paves the way for a future commit to make use of this metadata for the
template type-checking system.

Testing strategy: this commit is a refactoring which introduces no new
functionality, so existing tests are sufficient.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh 410151b07f fix(ivy): check [class] and [style] bindings properly (#29698)
Previously, bindings to [class] and [style] were treated like any other
property binding. That is, they would result in type-checking code that
attempted to write directly to .class or .style on the element node.

This is incorrect, however - the mapping from Angular's [class] and [style]
onto the DOM properties is non-trivial.

For now, this commit avoids the issue by only checking the expressions
themselves and not the assignment to the element properties.

Testing strategy: TCB tests included.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh 073d258deb feat(ivy): template type-checking for '#' references in templates (#29698)
Previously the template type-checking engine processed templates in a linear
manner, and could not handle '#' references within a template. One reason
for this is that '#' references are non-linear - a reference can be used
before its declaration. Consider the template:

```html
{{ref.value}}
<input #ref>
```

Accommodating this required refactoring the type-checking code generator to
be able to produce Type Check Block (TCB) code non-linearly. Now, each
template is processed and a list of TCB operations (`TcbOp`s) are created.
Non-linearity is modeled via dependencies between operations, with the
appropriate protection in place for circular dependencies.

Testing strategy: TCB tests included.

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh 9f5288dad3 feat(ivy): type-checking for some previously unsupported expressions (#29698)
This commit adds support for the generation of type-checking expressions for
forms which were previously unsupported:

* array literals
* map literals
* keyed property accesses
* non-null assertions

Testing strategy: TCB tests included.

Fixes #29327
FW-1218 #resolve

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh e3d5d41140 test(ivy): add tests for type_check_block.ts (#29698)
This commit adds a test suite for the Type Check Block generation which
doesn't require running the entire compiler (specifically, it doesn't even
require the creation of a ts.Program).

PR Close #29698
2019-04-19 11:15:25 -07:00
Alex Rickabaugh 0df719a461 feat(ivy): register NgModules with ids when compiled with AOT (#29980)
This commit adds registration of AOT compiled NgModules that have 'id'
properties set in their metadata. Such modules have a call to
registerNgModuleType() emitted as part of compilation.

The JIT behavior of this code is already in place.

This is required for module loading systems (such as g3) which rely on
getModuleFactory().

PR Close #29980
2019-04-19 11:12:21 -07:00
Alex Rickabaugh 4229b41057 test(ivy): replace ɵ with escape code (#29980)
PR Close #29980
2019-04-19 11:12:20 -07:00
Kara Erickson 9b93bd625f fix(ivy): ensure views created in constructors dont break queries (#29983)
Previous to this change, we assumed embedded views could only be created after
their parent template node had completed processing. As a result, we only set
up query logic for containers after directives on the node were created.
However, this assumption didn't take into account the case where a directive
on a template node could create views in its constructor.

This commit fixes query logic to work with views created in constructors.
In that case, we need to create a query container before the new view is
rendered so query results in the view aren't lost. But since the query container
is created before directives have completed processing, we also have to ensure
that query results gathered later on the template node are inserted before that
query container. Otherwise, query results in embedded views will clobber query
results on template nodes.

This splice mode may be slightly slower than the normal matching for queries on
containers, but we should only fall back to this strategy in the edge case where
views are created in constructors. (We should encourage developers to create
views in ngOnInit instead).

PR Close #29983
2019-04-19 10:01:32 -07:00
Andrew Kushnir f9bb53a761 fix(ivy): allow TestBed.createComponent to create components in isolation (#29981)
Prior to this change, components created via TestBed.createComponent in the same test were placed into the same root context, which caused problems in conjunction with fixture.autoDetectChanges usage in the same test. Specifically, change detection was triggered immediately for created component (starting from the 2nd one) even if it was not required/desired. This commit makes Ivy and VE behavior consistent: now every component created via TestBed.createComponent is isolated from each other. Current solution uses host element id naming convention, which is not ideal, but helps avoid public API surface changes at this point (we might revisit this approach later).

Note: this commit also adds extra tests to verify bootstrap and change detection behavior in case of multiple components in `bootstrap` array in @NgModule, to make sure this behavior is aligned between Ivy and VE.

PR Close #29981
2019-04-19 09:45:52 -07:00
Paul Gschwendtner c1d5fbd0ad refactor(core): static-query template strategy should not parse stylesheets (#29876)
Currently the `template-strategy` for the static query migration uses the
Angular compiler in order to determine the query timing. This is problematic
as the AngularCompilerProgram also collects metadata for referenced
component stylesheets which aren't necessarily present. e.g. in a CLI
project the component can reference a Sass file. It's not guaranteed
that the standalone Angular compiler plugin supports Sass without
custom logic that is brought in by the Angular CLI webpack plugin.

In order to avoid any failures for invalid stylesheets, we just disable
normalizing of all referenced stylesheets.

PR Close #29876
2019-04-18 18:22:09 -07:00
Paul Gschwendtner ca591641c7 refactor(core): allow developers to select static-query migration strategy (#29876)
Currently there are two available migration strategies for the `static-query`
schematic. Both have benefits and negatives which depend on what the
developer prefers. Since we can't decide which migration strategy is the
best for a given project, the developer should be able to select a specific
strategy through a simple choice prompt.

In order to be able to use prompts in a migration schematic, we need to
take advantage of the "inquirer" package which is also used by the CLI
schematic prompts (schematic prompts are usually only statically defined
in the schema). Additionally the schematic needs to be made "async"
because with prompts the schematic can no longer execute synchronously
without implementing some logic that blocks the execution.

PR Close #29876
2019-04-18 18:22:09 -07:00
Paul Gschwendtner 2ba799ddc7 fix(bazel): do not typecheck core schematic files (#29876)
Currently for Angular Bazel projects, NGC needs to be run in the
"postinstall" NPM script in order to generate required summary files.

We need to update the postinstall `tsconfig` to not check/re-build the
`@angular/core` schematic code which has transitive dependencies
which are only available inside of a CLI project. As this is not guaranteed
to be the case with Angular Bazel projects, we need to make sure that
we don't check/re-build these files.

PR Close #29876
2019-04-18 18:22:09 -07:00
Kevin Newman 22294dfad1 docs(animations): fixed some closing brackets on query animation page (#29854) (#29855)
PR Close #29855
2019-04-18 18:19:48 -07:00
Keen Yee Liau 0629ebd9e9 build(bazel): Bump CLI and @angular-devkit/* to v8 beta 15 (#29966)
PR Close #29966
2019-04-18 13:53:33 -07:00
Brandon 78146c1890 docs: update extra options available for RouterModule.forRoot() method (#29846)
PR Close #29846
2019-04-17 17:25:31 -07:00
Filipe Silva e1f51eaa55 feat(compiler-cli): export tooling definitions (#29929)
PR Close #29929
2019-04-17 17:23:01 -07:00
Filipe Silva e5905bb035 fix(core): use shakeable global definitions (#29929)
The `ngDevMode` and `ngI18nClosureMode` are special in that they should be set to `false` on production builds in order to shake out code associated with it.

Angular CLI does this in 5fc1f2499c/packages/angular_devkit/build_angular/src/angular-cli-files/models/webpack-configs/common.ts (L279-L282).

But in https://github.com/angular/angular/pull/28689 the toplevel usage was changed from `ngDevMode` to `global['ngDevMode']` (and the same for `ngI18nClosureMode`). This indirection prevents the static analysis in Terser from effecting the replacement.

PR Close #29929
2019-04-17 17:23:01 -07:00
Alex Eagle b9251fd707 build: Remove cc_binary dependency on brotli (#29912)
Just use the JavaScript port instead. We don't care about speed since we compress once as a build step.

PR Close #29912
2019-04-17 17:20:16 -07:00
Alan Agius 4bde40f7c2 fix(core): don't include a local `EventListener` in typings (#29809)
With dts bundles, `core.d.ts` will include an `EventListener` class as it's used in 303eae918d/packages/core/src/debug/debug_node.ts (L32)

This will conflict with the DOM EventListener, as anything in `core.d.ts` which is using the DOM EventListener will fallback in using the one defined in the same module and hence build will fail because their implementation is different.

With this change, we rename the local `EventListener` to `DebugEventListener`, the later one is non exported.

Fixes #29806

PR Close #29809
2019-04-17 16:45:35 -07:00
Greg Magolan 506f478f08 build(bazel): fix deps of test (#29799)
PR Close #29799
2019-04-17 13:02:03 -07:00
Greg Magolan 8a3a556c0c build(bazel): fix failure in http_server target due to transitive npm deps (#29799)
PR Close #29799
2019-04-17 13:02:03 -07:00
Greg Magolan 7edfcf948f build(bazel): update to nodejs rules 0.27.12 and pin versions in @angular/bazel peer deps and for @bazel/schematics (#29799)
PR Close #29799
2019-04-17 13:02:03 -07:00
JoostK 83291f01b0 fix(ivy): let ngtsc unwrap expressions when resolving `forwardRef` (#29886)
Previously, ngtsc would fail to resolve `forwardRef` calls if they
contained additional parenthesis or casts. This commit changes the
behavior to first unwrap the AST nodes to see past such insignificant
nodes, resolving the issue.

Fixes #29639

PR Close #29886
2019-04-17 12:52:34 -07:00
JoostK 725148a44d feat(ivy): let ngtsc statically evaluate `Array.concat` calls (#29887)
Previously, only static evaluation of `Array.slice` was implemented in
ngtsc's static evaluator. This commit adds support for `Array.concat`.

Closes #29835

PR Close #29887
2019-04-17 12:49:13 -07:00
Andrew Kushnir 696e520842 fix(ivy): make metadata calls side-effect free in Closure (#29947)
When compiling Angular classes, the compiler may decide to append statements with specific metadata that's only required for JIT. This includes things like decorator metadata as well as NgModule scope data.

When the compiler generates such calls, the call sites are marked with Uglify's PURE annotation, so the optimizer will remove them in production builds. However, Closure does not have the PURE (or similar) annotation. We have a utility function `noSideEffects` in the runtime for this purpose. This commit wraps `setClassMetadata` and `setNgModuleScope` function bodies in `noSideEffect` closures to allow Closure remove them.

PR Close #29947
2019-04-17 12:20:51 -07:00
Pawel Kozlowski 5fee9daa5b fix(ivy): properly coalesce event handler in presence of queries (#29957)
The `TNode.cleanup` data structure can contain sequences of 4-element
sequence of entries (event handlers, directive outputs) mixed with
2-element sequence of entries (QueryList cleanup). Before this fix
we would always skip 4 elements in the `TNode.cleanup` while looking
up event handler cleanups. 4-element skips are not correct in case
of query cleanup presence and this commit corrects the algorithm to
jump 4 or 2 elements depending on a type of cleanup encountered.

PR Close #29957
2019-04-17 12:20:00 -07:00
Keen Yee Liau 1a56cd5c0b fix(language-service): Use proper types instead of any (#29942)
PR Close #29942
2019-04-17 12:17:13 -07:00
Keen Yee Liau a48d288ff8 build(language-service): no need to bootstrap init_node_spec.js (#29937)
PR Close #29937
2019-04-17 12:13:39 -07:00
Kara Erickson d9c39dcab0 fix(ivy): directiveInject should fall back to inject (#29948)
If a component has its definition set by defineComponent (as opposed to
JIT getter), then it will generate a factory that uses directiveInject()
to retrieve its dependencies. This can be problematic in test code because
tests could use the injection utility before bootstrapping the component,
and directiveInject() relies on the view having been created.

This commit tweaks directiveInject() to fall back to inject() if the view
has not been created. This will allow injection to work in tests even if
it is called before the component is bootstrapped.

PR Close #29948
2019-04-16 19:31:46 -07:00
Kara Erickson ca2462cff7 fix(ivy): support providing components and dirs in tests (#29945)
Previous to this commit, providing a component or directive in a test
module without @Injectable() would throw because the injectable factory
would not be found. Providing components in tests in addition to declaring
or importing them is not necessary, but it should not throw an error.

This commit ensures factory data is saved when component defs and directive
defs are created, which allows them to be processed by the module injector.

Note that bootstrapping is still required for this setup to work because
directiveInject() does not support cases where the view has not been
created. This case will be handled in a future commit.

PR Close #29945
2019-04-16 19:14:17 -07:00
Kara Erickson 1794a8e42a fix(ivy): coalesced listeners should preventDefault if any returns false (#29934)
We had a bug where event.preventDefault() was not always called if listeners
were coalesced. This is because we were overwriting the previous listener's
result every time we called the next listener, so listeners early in the chain
that returned false would be ignored and preventDefault would not be called.

This commit fixes that issue, so now preventDefault() is called if any listener
in a coalesced chain returns false. This brings us in line with View Engine
behavior.

PR Close #29934
2019-04-16 13:36:27 -07:00
Filipe Silva 86a3f90954 fix(compiler-cli): pass config path to ts.parseJsonConfigFileContent (#29872)
The config path is an optional argument to `ts.parseJsonConfigFileContent`. When passed, it is added to the returned object as `options.configFilePath`, and `tsc` itself passes it in.

The new TS 3.4 [incremental](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html) build functionality relies on this property being present: 025d826339/src/compiler/emitter.ts (L56-L57)

When using The compiler-cli `readConfiguration` the config path option isn't passed, preventing consumers (like @ngtools/webpack) from obtaining a complete config object.

This PR fixes this omission and should allow JIT users of @ngtools/webpack to set the `incremental` option in their tsconfig and have it be used by the TS program.

I tested this in JIT and saw a small decrease in build times in a small project. In AOT the incremental option didn't seem to be used at all, due to how `ngc` uses the TS APIs.

Related to https://github.com/angular/angular-cli/issues/13941.

PR Close #29872
2019-04-16 13:36:08 -07:00
Filipe Silva 2bfb6a02e2 fix(router): support non-NgFactory promise in loadChildren typings (#29832)
PR Close #29832
2019-04-16 10:46:12 -07:00
Andrew Kushnir 5f1b6372c7 fix(ivy): multi provider override support in TestBed (#29919)
Overriding multi provider values (providers with `multi: true` flag) via TestBed require additional handling: all existing multi-provider values for the same token should be removed from the override list, so that they are not included into the final value of a given provider. This commit adds this logic to make sure we handle multi providers correctly.

PR Close #29919
2019-04-16 10:28:40 -07:00
Kristiyan Kostadinov 5d824c4153 fix(ivy): DebugNode.properties not preserving type of values (#29914)
Fixes the `DebugNode.properties` casting all of the values to a string.

This PR resolves FW-1253.

PR Close #29914
2019-04-16 09:50:44 -07:00
Yun Peng ca755a6b72 build: Fix label name (#29777)
Fix the following error with future Bazel version:
```
 Invalid label: invalid target name 'internal/npm_package:npm_package.bzl': target names may not contain ':'
```

PR Close #29777
2019-04-16 09:50:19 -07:00
Matias Niemelä 2deac0a412 perf(ivy): cache multiple reads to an element's stylingContext (#29818)
Because the styling context may be stored in a different location
and be apart of a sub array, reading the styling context each time
a host binding is evaluated is costly. This patch ensures that the
active styling context is cached so that multiple interactions with
styling bindings can easily retrieve the styling context efficiently.

PR Close #29818
2019-04-16 09:49:32 -07:00
Alex Rickabaugh 9147092a15 Revert "feat(ivy): use i18n locale data to determine the plural form of ICU expressions (#29249)" (#29918)
This reverts commit 6a8cca7975.

PR Close #29918
2019-04-15 16:55:51 -07:00
Paul Gschwendtner b0c1282fbe refactor(core): migrations do not properly handle multiple templates in source file (#29841)
Currently if there are multiple source files within a given
TypeScript source file, only the last template in the source
file is checked as we store templates in a `Map` with the
source file paths as keys.

This is problematic as multiple templates can live within the
same source file and we therefore accidentally overwrite
existing entries in the resolved templates map.

PR Close #29841
2019-04-15 11:13:39 -07:00
Paul Gschwendtner 446e3573e3 refactor(core): add static-query template strategy (#29815)
Introduces a new strategy for the `static-query` schematic that
is enabled by default. In order to provide a migration that works
for the most Angular applications and makes the upgrade as easy
as possible, the template strategy leverages the view engine
Angular compiler logic in order to determine the query timing
that is currently used within applications using view engine.

PR Close #29815
2019-04-15 10:53:54 -07:00