The package.json esm2015 points to the wrong path.
"esm15" should be "esm2015"
Service Worker can't be compiled with use of Closure Compiler
PR Close#20800
Not every application is served from the domain root. The Service
Worker made a bad assumption that it would be, and so requested
/ngsw.json from the domain root.
This change corrects this assumption, and requests ngsw.json without
the leading slash. This causes the request to be interpreted
relative to the SW origin, which will be the application root.
The Service Worker contains a mechanism by which it will postMessage
itself a signal to initialize its caches. Through this mechanism,
initialization happens asynchronously while keeping the SW process
alive.
Unfortunately in Firefox, the SW does not have the ability to
postMessage itself during the activation event. This prevents the
above mechanism from working, and the SW initializes on the next
fetch event, which is often too late.
Therefore, this change has the application wait for SW changes and
tells each new SW to initialize itself. This happens in addition to
the self-signal that the SW attempts to send (as self-signaling is
more reliable). That way even on browsers such as Firefox,
initialization happens eagerly.
Currently a bug exists where attempting to inject SwPush crashes the
application if Service Workers are unsupported. This happens because
SwPush doesn't properly detect that navigator.serviceWorker isn't
set.
This change ensures that all passive observation of SwPush and
SwUpdate doesn't cause crashes, and that calling methods to perform
actions on them results in rejected Promises. It's up to applications
to detect when those services are not available, and refrain from
attempting to use them.
To that end, this change also adds an `isSupported` getter to both
services, so users don't have to rely on feature detection directly
with browser APIs. Currently this simply detects whether the SW API
is present, but in the future it will be expanded to detect whether
a particular browser supports specific APIs (such as push
notifications, for example).
Currently, the way to not use the SW is to not install its module.
However, this means that you can't inject any of its services.
This change adds a ServiceWorkerModule.disabled() MWP, that still
registers all of the right providers but acts as if the browser does
not support Service Workers.
Saving `oldProgram` in `AngularCompilerProgram` instances is causing a memory leak for unemitted programs.
It's not actually used so simply not saving it fixes the memory leak.
Fix#20691
PR Close#20692
This changes XhrBackend to not strip the XSSI prefix from error text
if such a prefix is present but the remaining body does not parse as
JSON.
PR Close#19958
Previously, XhrBackend would call JSON.parse('') if the response body was
empty (a 200 status code with content-length 0). This changes the XhrBackend
to attempt the JSON parse only if the response body is non-empty. Otherwise,
the body is left as null.
Fixes#18680.
Fixes#19413.
Fixes#19502.
Fixes#19555.
PR Close#19958
Previously, HttpClient used the overly clever test "body || null"
to determine when a body parameter was provided. This breaks when
the valid bodies '0' or 'false' are provided.
This change tests directly against 'undefined' to detect the presence
of the body parameter, and thus correctly allows falsy values through.
Fixes#19825.
Fixes#19195.
PR Close#19958
The errors produced when error were encountered while interpreting the
content of a directive was often incomprehencible. With this change
these kind of error messages should be easier to understand and diagnose.
PR Close#20459
The type-check block generated with `"fullTemplateTypeCheck"` was
invalid if the it contained a template ref as would be generated
using the `else` micro-syntax of `NgIf`.
Fixes: #19485
PR Close#20463
- update to TypeScript 2.5
- point the 2.4 typings test at the previous typescript version, so we
don't break it accidentally
- widen the peerDeps from Angular packages that depend on TypeScript
- update to latest TypeScript 2.5 compatible Bazel rules
- move .bazelrc to tools/bazel.rc per https://docs.bazel.build/versions/master/best-practices.html#bazelrc
PR Close#20175