Commit Graph

3699 Commits

Author SHA1 Message Date
George Kalpakas 8f120aff33 refactor(service-worker): DRY up SW registration logic (#21842)
PR Close #21842
2019-04-25 12:29:58 -07:00
JiaLi.Passion 4cfba58072 feat(service-worker): allow configuring when the SW is registered (#21842)
Fixes #20970

PR Close #21842
2019-04-25 12:29:58 -07:00
George Kalpakas aa53d6cc6d docs(service-worker): improve `SwRegistrationOptions` docs and add example (#21842)
PR Close #21842
2019-04-25 12:29:58 -07:00
George Kalpakas be28a6ad8e test(service-worker): expand `SwRegistrationOptions` tests and move to separate file (#21842)
PR Close #21842
2019-04-25 12:29:58 -07:00
deebloo 39c0152b76 feat(service-worker): expose `SwRegistrationOptions` token to allow runtime config (#21842)
Previously, the ServiceWorker registration options should be defined as
an object literal (in order for them to be compatible with Ahead-of-Time
compilation), thus making it impossible to base the ServiceWorker
behavior on runtime conditions.
This commit allows specifying the registration options using a regular
provider, which means that it can take advantage of the `useFactory`
option to determine the config at runtime, while still remaining
compatible with AoT compilation.

PR Close #21842
2019-04-25 12:29:58 -07:00
George Kalpakas d7887ab4ab refactor(service-worker): rename `RegistrationOptions` to `SwRegistrationOptions` (#21842)
This is in preparation of making `RegistrationOptions` part of the
public API (in a subsequent commit).

PR Close #21842
2019-04-25 12:29:58 -07:00
George Kalpakas 2236ea4359 test(upgrade): rename `angular.module()` to `angular.module_()` (#30126)
With #30058, the ngUpgrade internal `angular.module()` method was
renamed to `angular.module_()` (to avoid a webpack bug).

Merging #29794 afterwards resulted in some broken tests, because it
still used the old `angular.module()` method name. (The PR had been
tested on CI against a revision that did not contain the rename.)

This commit fixes the broken tests by renaming the remaining occurrences
of `angular.module()`.

PR Close #30126
2019-04-25 12:01:18 -07:00
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